如何设计一个秒级100万级的订单支付架构

在订单支付系统中，往往会面临这样的问题：如何保证每秒万级甚至10万百万级的支付请求或者订单请求。在讲这个这个设计之前来分析下要实现这个秒级100万级的订单支付架构会面临怎样的问题。

1.DB层：读写的压力，高可用，数据库的一致性。

1.1.假定我们使用是的mysql，单库，是无法支撑这个数据量级的并发操作的，我们单库能轻松应对10万级的访问但是绝对支撑不了10万级的写操作。

1.2.假定我们解决了读写的压力问题，我们还将面临高可用的问题，怎样的方案能确保数据库集群宕机后保证数据库的访问不受影响。

1.3.假定我们解决了高可用的问题，我们还需要保证数据库的一致性问题，否则我们将面临数据丢失和不一致的问题。

接下我们将针对上面3个问题来逐步分析：

1.1.数据库的读写问题，这是这个架构设计里面最重要最核心的问题。我们知道，通常解决读写问题是通过分库分表来解决的。分库分表可以把执行sql的压力根据既定的规则分摊到不同的库和表，从而减小数据库的压力。不论是是分库还是分表都是为了减小sql执行等待的时间。接下来开始我关于分库分表的设计，以订单表的设计为例：我们很清楚的知道分库分表要解决的问题是订单表的id主键设计问题，要保证在所有库和表中是唯一的。怎么保证呢，唯一性很容易想到UUID，UUID确实可以保证全局唯一，不过UUID存在两个问题：UUID一段随机的字符串是没有顺序的，执行查询的效率是很低的；UUID是没有业务含义的不具备业务含义的区分。

设计：我们已用的ID来做键值的区分依据，采用二叉树的方式来分库分表。我们假设我们把order分成16个库，每个库里面有10张表，这样我们就有160张表