背景:
协程 用户空间进行 线程需要内核和用户空间
进程大小 4G
线程 4M 保存寄存器中的内容,在内核和用户态切换,需要在内核空间完成
协程大小 1协程 1—>2.5Kb
协程切换成本小,内存占用小。用户态的切换,实际上就是寄存器的加载
进程 操作系统会以进程为单位,分配系统资源(cpu时间片,内存等资源),进程是资源分配的最小单位
进程的安全性比较高通信成本大 IPC ===> 信号 管道 共享内存 socket网络通信 共享文件
线程 操作系统调度(cpu调度)执行的最小单位
共享资源,隔离性差通信成本少 通过同步机制访问共享资源即可完成通信线程是寄生在进程之上的
协程切换完全在用户空间进行,线程切换涉及特权模式切换,需要在内核空间完成
线程有不同的栈,堆区,代码区这些空间共用,线程是轻量级的进程
限制goroutine的方法
只使用buffer和channel来限制
只使用sync同步机制
channel和sync的组合方式来限制
Golang协程调度器
GMP
G:goroutine M:thread P:processor
多态
多态三要素:
有个父类的接口
有子类重写父类的全部接口方法
父类(接口类型)指针(引用类型) 指向子类对象
有抽象层 有实现层 一旦有interface出现 一定要针对interface写业务
方法不能重载
defer
defer 先进栈 (stack)再出栈 先入后出
return 之后的语句先执行, defer后面的语句后执行
函数的有名返回值在调用的时候就被定义了,为类型 0值 ,其作用域为函数的全局
slice中new的使用问题
make只用于slice map 以及channel的初始化(非零值);make返回的是这三个引用类型本身
而new用于类型的内存分配,并且内存置为零;而new返回的是指向类型的指针
slice 拼接问题
两个slice 在 append的时候,需要将第二个slice 用…打散再拼接
s1 = append(s1, s2…)
多态三要素
有interface接口, 并且有接口定义的方法
有子类去重写interface的接口
有父类指针指向子类的具体对象
var p People = &Student{} 正确的
interface{} 和 *interface{}
*interface 本身不是万能指针,就是eface结构体的地址
如果以_interface{}作为形参, 那么他只能够接收_interface{}类型的实参
空接口 eface
非空接口 iface
channel
给一个nil channel发送数据,造成永久阻塞
从一个nil channel接收数据, 造成永久阻塞
给一个已经关闭的channel发送数据,引起panic
从一个已经关闭的channel接收数据,如果缓冲区中为空,则返回一个零值
无缓冲的channel是同步的,而有缓冲的channel是非同步的
空读写阻塞, 写关闭异常,读关闭空零
WaitGroup
如果wg中没有资源(Add是添加一个资源,Done是消费一个资源), wait将不再阻塞
如果新开辟的goroutine 还没有进行ADD,就执行到了Wait, Wait就会立刻返回,主main线程退出,进程就退出
const N = 10var wg = &sync.WaitGroup{}func main() {for i :=0; i<N; i++ {wg.Add(1) // main 完成, 要保证Wait之前有Add已经添加了资源go func(i init) {defer wg.Done()}(i)wg.Wait()}
事务
事务的特性:ACID
原子性(atomic):
一致性(Consistency):
隔离性 (Isolation):防止多个事务交叉执行,导致数据不一致
持久性(Durability):事务处理结束后, 对数据的修改是永久的
ACID特性: 统一提交,失败回滚
事务:要不不做,要么全套
CAP 分布式特性
一致性Consistency
缺点: 由于存在数据同步的过程,写操作的响应会有一定的延迟
为了保证数据的一致性会对资源暂时锁定,待数据同步完成释放锁定资源如果请求数据同步失败的节点则会返回错误信息,一定返回旧数据
可用性Availability
Reads and writes always succeed 服务一直可用,而且正常响应时间
高可用性,牺牲性能换可用性
分区容错性Partition Tolerance
the system continues to operate despite arbitrary message loss or failure part of the system
分布式系统中,尽管部分节点出现任何消息丢失或者故障,系统应继续运行
commit: all nodes see the same data at the same time
选择一: 牺牲一致性(c), 满足可用性(a), 响应旧数据给用户
选择二: 牺牲可用性(a),满足数据一致性(c)
分区容错性(p)必选
cp放弃a
分布式系统不要求强的可用性,允许系统停机或者长时间无响应的话
Redis HBase Zookeeper
场景
跨行转账:一次转账请求要求等待双方银行系统都完成整个事务才算完成
淘宝订单退款 12306买票
都是在可用性和一致性之间舍弃了一致性而选择了可用性
最终是一致,但是短期内不一定一致
BASE理论(大型分布式系统)
通过牺牲强一致性获得高可用性(与ACID理论对立,传统数据库追求强一致性模型)
Basically Available —基本可用
对响应时间的妥协
对功能损失的妥协(服务降级,)
Soft state 软状态
强状态:所有节点的数据必须全部一致,才能对外提供数据。追求强一致性
软状态:分布式系统中,允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性 。 追求最终一致性(允许短时间不一致)
Evebtually consistent (最终一致性)
