京东评价系统海量数据存储设计

引入了这么多的存储方案就是为了解决大数据量存储问题及实现数据服务的高可用,同时合理的部署设计与相应的容灾处理也必须要有的.以上数据存储基本都使用多机房主从方式部署,各机房内部实现主从结构进行数据同步.如图：

mysql集群数据库拆库后需要对各分库进行多机房主从部署,系统应用进行读写分离并根据机房进行就近调用,当主机房数据库出现故障后将故障机房的数据操作都切换到其它机房,待故障排除后再进行数据同步与流量切换.

使用主从机房部署的方式所有数据更新操作都要在主库上进行,而当主机房故障是需要通过数据库主从关系的重建、应用重新配置与发布等一系列操作后才能解决流量切换,过程较为复杂且影响面较大,所以这是个单点问题,为此实现数据服务多中心将是我们下一个目标.

多中心根据特定规则将用户分别路由到不同机房进行数据读写,各机房间通过数据总线进行数据同步,当某一机房出现故障,只需要一键操作便能快速地将故障机房的用户流量全部路由到其它机房,实现了数据的多写多活,也进一步实现了服务的高可用.数据多中心如下：

hbase集群目前使用的是京东的公有集群,实现了双机房主备部署,主集群出现故障后自动将流量切换到备用集群,而当hbase整个集群故障时还可对其进行降级,同步只写入缓存及备用存储mongo,待集群恢复后再由后台异步任务将数据回写到hbase当中.

搜索集群根据商品编号进行索引数据分片多机房主从部署,并保证至少3个从节点并部署于多个机房当中,当主节点出现故障后从这些从节点选取其中一个作为新的主提供服务.集群主节点只提供异步任务进行索引更新操作,从节点根据应用机房部署情况提供索引查询服务.

Redis缓存集群主从部署仍是标配,主节点只提供数据的更新操作,从节点提供前台缓存读服务,实现缓存数据的读写分离,提升了缓存服务的处理能力.当主节点出现故障,选取就近机房的一个从节点作为新主节点提供写服务,并将主从关系进行重新构建.任何一从节点出现故障都可通过内部的配置中心进行一键切换,将故障节点的流量切换到其它的从节点上.

?总结

整体数据架构并没有什么高大上的设计,而且整体数据架构方案也是为了解决实际痛点和业务问题而演进过来的.数据存储方案上没有最好的,只有最适合的,因此得根据不同的时期、不同的业务场景去选择合适的设计才是最关键的,大家有什么好的方案和建议可以相互讨论与借鉴,系统的稳定、高性能、高可用才是王道.

文章出处：开涛的博客(公众号ID：kaitao-1234567)

（编辑：济源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!