对强一致性模型的思考
最近在完善强一致性的存储系统的时候,发现对强一致性的理解不够透彻,步入了误区
强一致性存储系统的简单理解和定义
强一致性的理解:
resp返回给客户端之前,保证所有节点的内容都一致。
只要保证存储系统,在同步追加过程中强一致性,那么就能保证各个节点也为强一致性
最近在完善强一致性的存储系统的时候,发现对强一致性的理解不够透彻,步入了误区
强一致性的理解:
resp返回给客户端之前,保证所有节点的内容都一致。
只要保证存储系统,在同步追加过程中强一致性,那么就能保证各个节点也为强一致性
在使用grpc的时候,对通信协议有着调用链追踪的需求
这部分要封装进框架,对使用方透明,因此协程上下文(Goroutine Local Storage)的用法顺理成章
但是搜索了些资料,发现golang并没有gls
google提供的解决方法是使用golang.org/x/net/context包来传递上下文信息
这是GPRC+ETCD服务发现的一种变种实现
在服务端代码的封装上有很大的区别,一个简单的服务发现系统中,服务端之间的状态互不影响
在主从系统中,主需要知道从的IP来向从复制数据(或者反过来从需要知道主的IP来拉取数据),当主挂了,需要选举一台从来切换成主
先安装protobuf的C库
然后安装protoc工具
1 | go get -u github.com/golang/protobuf/proto |
最后安装gRPC-go
最近公司做用户数据迁移,4TB的量,租借了20Gb的带宽,完整迁移需要25天,给的迁移期只有30天,整个迁移过程的容错性和可靠性要非常强
另外由于数据的特殊性,用户数据的错乱比起迁移失败等等无疑是更严重的问题,所以迁移过程要保证强独立性
然而迁移过程的开发时间只有5天,测试时间5天,非常仓促(实际上线后确实遇到不少问题,又花了5天才全部解决)
需求是图片,视频等文件的存储
属于少写多读的场合,修改操作较少。文件粒度是大小文件都有。
先谈谈fastdfs,我在公司已经应用了两年了,对他的基本特性比较熟悉,在这种场合下有这些优缺点
golang的http上传文件的实现细节严格遵循了multipart/form-data的RFC1867规范,细节网上已经分析了很多了
本篇只是讨论golang上如何使用官方库实现的框架
客户端上传很简单,利用"mime/multipart"官方库即可完成上传
可以看到这里上传文件时全部加载在内存的bodyBuf字符数组中,所以这里只是上传小文件,大文件这么上传会写爆内存
首先是轮子地址:
https://github.com/tedcy/fdfs_client
最近用go做项目,要用到fastdfs
看了下github上star最多的fastdfs go客户端https://github.com/weilaihui/fdfs_client,稍微看了下感觉不太好。
codis在迁移方案上下了不少功夫,我认为codis和twemproxy最大的区别之一是:
codis是面向slot的管理,而twemproxy只是面向redis后端的管理
codis迁移是由Topom结构体的SlotCreateAction方法开始的,这个方法也许叫做SlotMoveToGroupCreateAction更加容易让人理解
这个方法需要两个参数,slot id以及group id,目的是吧这个slot(以及该slot的所有key)迁移到目标group中
SlotCreateAction检测了一些边界条件,例如slot正在被迁移,或者该slot已经存在与目标group
记录下踩到的坑
一 接口
1 | package main |
对于demo1来说数组能够容纳下这一块数据,因此array2依然指向array1,array1被改为[1 3 4]
对于demo2来说array3底层的数组能够容纳下这一块数据,因此array4依然指向array3底层的数组,array3被改为[1,3]