业务连续性专题：一致性和并发度的平衡

对于互联网应用，高并发是一个基本的要求。一个互联网应用可以支持的并发访问量，很大程度上可以体现一个团队的技术底蕴。对于金融类应用，一致性又是一个基本的前提。一致性保障的不足，往往会带来资金安全上的风险。那对于互联网金融的应用，天然会存在并发度和一致性的矛盾。

互联网金融系统架构，对于这两者的矛盾，需要的是兼顾的考虑，而不是一个取舍。要做到一致性和并发度的坚固，需要从去点单、分布式和事务设计三方面去考虑架构的设计。

首先是去点单。单点是影响并发度的最大阻碍。在我们的系统架构上，单点一般存在于两个地方：配置信息和热点数据。

对于配置信息，天然存在写少读多的特性，我们可以采用多副本、分布式缓存、本地缓存等手段，去除访问的单点。

对于热点数据，就不一定是写少读多的特性了，很大可能是读写均衡甚至读少写多。对于提升热点数据更新的并发度，我们一般从打散和异步化两个方面去考虑。打散采用将热点数据拆分的方式，例如将一个大账号拆分成多个子账号，将总的营销额度拆分成各个区域营销额度，将集中的写操作分散。异步化通过将更新操作排队或者用日志记录代替数据更新，通过时间换空间的方式，提升并发度。

其次是分布式。这个就比较容易理解了：一致性基本上说的是同一个用户数据或者同一笔交易的一致性。所以，我们可以考虑将不同用户、不同交易打散到不同的存储上，提升访问的并发度。在架构上的实现，就是分区操作。分区的规则，需要适合业务场景的离散度要求，可以考虑用户、也可以考虑用一致性 hash、或者可以用时间戳。

最后是事务的设计上需要考虑高并发的要求。要保证数据的一致性，同时尽量降低架构的复杂度，我们一般在实现上还是会通过事务的方式来保证数据的一致性。

对于事务的设计，首先我们需要尽量避免长事务的出现，从而降低数据锁定的时间，提升事务的并发度。我们从几个方面考虑：

• 引入状态机，将和数据更新无关的外部调用等其他操作从事务中剥离出来，将一个长事务拆分成多个短事务。短事务保证数据更新的一致性，状态机保证短事务编排的一致性。

• 用 TCC 的方式，将协调多个系统的长事务拆分成单个系统 Try 和 Commit 两阶段的短事务。

• 通过事务性消息，将分布式事务拆分成多个本地事务。对于存在主功能的分布式事务，通过主功能事务中发送事务性消息驱动其他辅助功能更新的方式。通过保证主事务和消息的一致性，间接保证了各个系统之间数据的最终一致性。

总是，对于在保证数据一致性的前提下保证系统的高并发，可以从去单点、分散存储以及特殊的事务设计原则上来考虑。