“百亿红包背后的技术支撑”阅读笔记

传统方案下：

渠道层的所有业务都进入一套Server及数据库进行处理，会导致数据库及Server消耗较多资源。特别是数据库，因为应用服务的Server还可以进行流量上的分流，但是到达数据库时，数据库要保证事务处理一致性以及数据记录的唯一性，所以一般只有一个主库在工作（备库不参与），造成在业务高峰时段极易出现CPU高的问题。

分库分表方案：

按照一定规则，将Server及DB分成多个集群（set），每个集群处理只处理特定范围的交易：实现方式是通过一定的算法将交易分散到不通的集群处理。比如可以按照交易ID、也可以按照用户ID。

分库后，每一个集群就有多个server和一个DB组成：

这里面有个细节需要考虑，就是同一个红包，在多个人抢时，只能由一个服务器处理，否则的话，server与server之间要对抢红包的状态进行进一步的事务一致性处理，增加了复杂度。

所以同一个红包的请求，只能路由给同一个server。因此增加了一层基于红包ID的hash值分流。

上面的分库方案是单纬度的，由于抢红包这一场景可能存在延迟性，比如今天发的过两天再抢，因此在分库分表的处理上，还增加了“日期”这一维度。这样就可以做到冷热库分离，互不影响。同时，也减小了单表的大小。

比如：当月1号发的红包ID为1的在set1处理，2号发的红包ID为1的在set2处理。

我自己的理解是：由于红包有效期只有24小时，其实最多也就2个日期涉及的set会有热点，因此，按日期分库方案主要的作用还是在减小单set数据表的大小，数据表笑了，数据库处理的压力也就进一步降低了。所以，估计只有相邻的两个库是热点，然后热点逐渐向下一个服务器转移。