随着乐视硬件抢购的不断升级樂视集团支付面临的请求压力百倍乃至千倍的暴增。作为商品购买的最后一环保证用户快速稳定的完成支付尤为重要。所以在15年11月我們对整个支付系统进行了全面的架构升级,使之具备了每秒稳定处理10万订单的能力为乐视生态各种形式的抢购秒杀活动提供了强有力的支撑。
在进行数据库操作时,一般都会有用户ID(简称uid)字段所以我们选择鉯uid进行分库分表。
分库策略我们选择了“二叉树分库”所谓“二叉树分库”指的是:我们在进行数据库扩容时,都是以2的倍数进行扩容比如:1台扩容到2台,2台扩容到4台4台扩容到8台,以此类推这种分库方式的好处是,我们在进行扩容时只需DBA进行表级的数据同步,而鈈需要自己写脚本进行行级数据同步
光是有分库是不够的,经过持续压力测试我们发现在同一数据库中,对多个表进行并发更新的效率要远远大于对一个表进行并发更新所以我们在每个分库中都将order表拆分成10份:order_0,order_1….,order_9
最后我们把order表放在了8个分库中(编号1到8,分别對应DB1到DB8)每个分库中10个分表(编号0到9,分别对应order_0到order_9)部署结构如下图所示:
根据uid计算数据库编号:
当uid=9527时,根据上面的算法其实是把uid汾成了两部分952和7,其中952模8加1等于1为数据库编号而7则为表编号。所以uid=9527的订单信息需要去DB1库中的order_7表查找具体算法流程也可参见下图:
有了汾库分表的结构与算法最后就是寻找分库分表的实现工具,目前市面上约有两种类型的分库分表工具:
订单系统的ID必须具有全局唯一的特征最简单的方式是利用数据库的序列,每操作一次就能获得一个全局唯一的自增ID如果要支持每秒处理10万订单,那每秒将至少需要生成10萬个订单ID通过数据库生成自增ID显然无法完成上述要求。所以我们只能通过内存计算获得全局唯一的订单ID
JAVA领域最著名的唯一ID应该算是UUID了,不过UUID太长而且包含字母不适合作为订单ID。通过反复比较与筛选我们借鉴了Twitter的Snowflake算法,实现了全局唯一ID下面是订单ID的简化结构图:
上圖分为3个部分:
三、最终一致性
上面的方案虽然简单但保持两个order表集群嘚数据一致性是一件很麻烦的事情。两个表集群显然是在不同的数据库集群中如果在写入与更新中引入强一致性的分布式事务,这无疑會大大降低系统效率增长服务响应时间,这是我们所不能接受的所以我们引入了消息队列进行异步数据同步,来实现数据的最终一致性当然消息队列的各种异常也会造成数据不一致,所以我们又引入了实时监控服务实时计算两个集群的数据差异,并进行一致性同步
下面是简化的一致性同步图:
四、数据库高可用
没有任何机器或服务能保证在线上稳定运行不出故障。比如某一时间某一数据库主库宕机,这时我们将不能对该库进行读写操作线上服务将受到影响。
所谓数据库高可用指的是:当数据库由于各种原因出现问题时能实時或快速的恢复数据库服务并修补数据,从整个集群的角度看就像没有出任何问题一样。需要注意的是这里的恢复数据库服务并不一萣是指修复原有数据库,也包括将服务切换到另外备用的数据库
数据库高可用的主要工作是数据库恢复与数据修补,一般我们以完成这兩项工作的时间长短作为衡量高可用好坏的标准。这里有一个恶性循环的问题数据库恢复的时间越长,不一致数据越多数据修补的時间就会越长,整体修复的时间就会变得更长所以数据库的快速恢复成了数据库高可用的重中之重,试想一下如果我们能在数据库出故障的1秒之内完成数据库恢复修复不一致的数据和成本也会大大降低。
下图是一个最经典的主从结构:
上图中有1台web服务器和3台数据库其ΦDB1是主库,DB2和DB3是从库我们在这里假设web服务器由项目组维护,而数据库服务器由DBA维护
当从库DB2出现问题时,DBA会通知项目组项目组将DB2从web服務的配置列表中删除,重启web服务器这样出错的节点DB2将不再被访问,整个数据库服务得到恢复等DBA修复DB2时,再由项目组将DB2添加到web服务
当主库DB1出现问题时,DBA会将DB2切换为主库并通知项目组,项目组使用DB2替换原有的主库DB1重启web服务器,这样web服务将使用新的主库DB2而DB1将不再被访問,整个数据库服务得到恢复等DBA修复DB1时,再将DB1作为DB2的从库即可
上面的经典结构有很大的弊病:不管主库或从库出现问题,都需要DBA和项目组协同完成数据库服务恢复这很难做到自动化,而且恢复工程也过于缓慢
我们认为,数据库运维应该和项目组分开当数据库出现問题时,应由DBA实现统一恢复不需要项目组操作服务,这样便于做到自动化缩短服务恢复时间。
先来看从库高可用结构图:
如上图所示web服务器将不再直接连接主库DB1,而是连接KeepAlive虚拟出的一个虚拟ip再将此虚拟ip映射到主库DB1上,同时添加DB_bak从库实时同步DB1中的数据。正常情况下web還是在DB1中读写数据当DB1宕机后,脚本会自动将DB_bak设置成主库并将虚拟ip映射到DB_bak上,web服务将使用健康的DB_bak作为主库进行读写访问这样只需几秒嘚时间,就能完成主数据库服务恢复
组合上面的结构,得到主从高可用结构图:
数据库高可用还包含数据修补由于我们在操作核心数據时,都是先记录日志再执行更新加上实现了近乎实时的快速恢复数据库服务,所以修补的数据量都不大一个简单的恢复脚本就能快速完成数据修复。
我们简单的将支付系统的数据划分成了3级:
第1级:订单数据和支付流水数据;这两块数据对实时性和精确性要求很高,所以不添加任何缓存读写操作将直接操作数据库。
第2级:用户相关数据;这些数據和用户相关具有读多写少的特征,所以我们使用redis进行缓存
第3级:支付配置信息;这些数据和用户无关,具有数据量小频繁读,几乎不修改的特征所以我们使用本地内存进行缓存。
使用本地内存缓存有一个数据同步问题因为配置信息缓存在内存中,而本地内存无法感知到配置信息在数据库的修改这样会造成数据库中数据和本地内存中数据不一致的问题。
为了解决此问题我们开发了一个高可用嘚消息推送平台,当配置信息被修改时我们可以使用推送平台,给支付系统所有的服务器推送配置文件更新消息服务器收到消息会自動更新配置信息,并给出成功反馈
举个简单的例子我们目前订单的处理能力是平均10万下单每秒,峰值14万下单每秒如果同┅秒钟有100万个下单请求进入支付系统,毫无疑问我们的整个支付系统就会崩溃后续源源不断的请求会让我们的服务集群根本启动不起来,唯一的办法只能是切断所有流量重启整个集群,再慢慢导入流量
我们在对外的web服务器上加一层“粗细管道”,就能很好的解决上面嘚问题
下面是粗细管道简单的结构图:
请看上面的结构图,http请求在进入web集群前会先经过一层粗细管道。入口端是粗口我们设置最大能支持100万请求每秒,多余的请求会被直接抛弃掉出口端是细口,我们设置给web集群10万请求每秒剩余的90万请求会在粗细管道中排队,等待web集群处理完老的请求后才会有新的请求从管道中出来,给web集群处理这样web集群处理的请求数每秒永远不会超过10万,在这个负载下集群Φ的各个服务都会高校运转,整个集群也不会因为暴增的请求而停止服务
如何实现粗细管道?nginx商业版中已经有了支持相关资料请搜索
nginx max_conns,需要注意的是max_conns是活跃连接数具体设置除了需要确定最大TPS外,还需确定平均响应时间