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

当然,缓存设计时还有很多细节可以进行巧妙处理的,如：

• 当用户新发表一条评论,要实现前台实时展示,可以将新增的评论数向首屏列表缓存中追加最新的评论信息；
• 评论数是读多写少,这样就可以将评论数持久化到redis当中,只有当数据进行更新时通过异步的方式去将缓存刷新即可；评论数展示可通过nginx+lua的方式提供服务,服务请求无需回源到应用上,不仅提升服务性能,也能减轻应用系统的压力；
• 对于评论列表,通常访问的都是第一屏的数据,也就是第一页的数据,可以将第一页的数据缓存到redis当中,有数据更新时再通过异步程序去更新；
• 对于秒杀类的商品,评论数据可以结合本地缓存提前进行预热,这样当秒杀流量瞬间涌入的时候也不会对缓存集群造成压力；通过减短key长度、去掉多余属性、压缩文本等方式节省内存空间,提高内存使用率.

数据容灾与高可用

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

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

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

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

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

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

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

?总结

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

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

（编辑：ASP站长网）