京东丁俊:京东分布式K-V存储设计与挑战

  大多数企业梦寐以求的存储系统是什么样的呢?当图片、文章甚至视频需要存储时，你希望既不丢失还要提供高速读写的能力;当磁盘坏了，你的数据依然还在;当用户访问量成倍增长，读写能力依然保持高速。当大促来临，用户体验依然无差。这一切都是京东分布式K-V存储的设计原动力，京东商城-基础架构部丁俊在SACC大会《数据库架构设计与实践》现场分享了京东分布式K-V存储的设计与挑战。

　　京东分布式存储两大产品是非持久化存储JIMDB与持久化存储FBASE。其中，JIMDB兼容REDIS协议，在线弹性伸缩的，数据全部保存在内存的K-V存储系统;FBASE支持多协议，支持范围查找的持久化K-V存储系统。对一些对读写性能要求较高的场景，性能自然优先于数据可靠性，JIMDB是合适的选择;对数据可靠性要求高，数据量大，数据冷热分布明显的场景，选择FBASE是明智的。

　　丁俊表示，整个设计过程面临着诸多挑战，比如故障检测与恢复、在线扩容、高可用以及升级等，JIMDB的故障检测与恢复容易出现基数大、故障次数多，人工响应慢和误判等问题，出现这种问题的原因可能是部分网络故障或者服务程序繁忙造成响应慢。主要的解决方案是将故障检测程序独立部署，分散在不同机架上;投票决定，存活状态一票否决;一个机房部署多组，每组负责部分实例;宿主机agent辅助检测确认。

　　随着近两年京东618、双11大促的火热，业务增长远超预期，资源紧缺成为一种常态，这种情况下就需要考虑在线扩容的问题了。丁俊表示，扩容触发条件是单个分片内存占用大小和进出流量(CPU使用率)，而单个分片的大小主要考虑扩容过程的持续时间和CPU与内存的使用率。

　　在扩容之前，最好提前把将要变更的拓扑信息下发给客户端，客户端捕捉到特定异常后使用临时拓扑，扩容完成后临时拓扑变更为正式拓扑，这三步可以保证平滑扩容。但要注意数据迁移的最小单位为槽，单shard需要控制大小，避免迁移数据多时间长。

　　对于多副本异步复制，副本部署要求是跨物理机、跨机房、同城跨机房以及异地数据中心。至于JIMDB异地灾备，可直接部署slave，内存缓冲区;经过synclog模块，异地机房只是一个远程副本;集群间有复制关系。

　　如果需要升级，丁俊表示，内存中的数据需要做迁移，按照shard滚动升级，新版本的容器创建在同一台宿主机上，迁移完成后客户端捕捉到数据已迁移的异常，会使用新的拓扑。

　　至于持久化存储Fbase，KEY全局有序排列，支持多种复制模式，支持schema，支持模板列，插入时可以自动添加列，存储层LSM-Tree(Log-Structured Merge Tree)。适用场景是按key访问，或者单个partition内范围扫描。缺点是不能全局范围扫描，读取必须带有partition key，

　　兼容redis协议、partition second index等特性的Table，一个partition对应一个dataserver，有容量限制，需要提前规划。缓存有块缓存和KEY缓存两种方式，按照hash规则进行分区的，需要开启KEY级别的缓存。

　　新一轮的电商狂欢节又要来临，京东分布式K-V存储系统可准备好了吗?丁俊表示，未来的K-V存储将主要从redis数据结构、支持二级索引、支持事务三方面优化。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31077337/viewspace-2153969/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31077337/viewspace-2153969/