支撑百万并发的数据库架构如何设计？

一、一台数据库服务器在支撑每秒上万的请求，高峰期会出现下述问题：

1. 你的数据库服务器的磁盘 IO、网络带宽、CPU 负载、内存消耗，都会达到非常高的情况，数据库所在服务器的整体负载会非常重，甚至不堪重负了。
2. 高峰期时，单表数据量就大，SQL 性能就一般，这时加上你的数据库服务器负载太高导致性能下降，就会发现你的 SQL 性能更差了。
3. 最明显的一个感觉，就是你的系统在高峰期各个功能都运行的很慢，用户体验很差，点一个按钮可能要几十秒才出来结果。
4. 数据库服务器的配置不是特别的高的话，弄不好你还会经历数据库宕机的情况，因为负载太高对数据库压力太大了。

二、多台服务器分库支撑高并发读写

场景：上万并发请求的场景下

• 硬件设备：16 核 32G
• 支撑数量：每秒请求支撑超过 2000，一般控制在 2000 左右
  控制在这个程度，一般数据库负载相对合理，不会带来太大的压力，没有太大的宕机风险。

应用：

1. 部署个 5 台服务器，每台服务器上都部署一个数据库实例。
2. 每个数据库实例里，都创建一个一样的库，比如说订单库。此时在 5 或多台服务器上都有一个订单库，名字可以类似为：db_order_01，db_order_02，等等。
3. 每个订单库里，都有一个相同的表，比如说订单库里有订单信息表，那么此时 5 或多个订单库里都有一个订单信息表。
   例如：db_order_01 库里就有一个 tb_order_01 表，db_order_02 库里就有一个 tb_order_02 表。

思路：
        这就实现了一个基本的分库分表的思路，原来的一台数据库服务器变成了 5 或多台数据库服务器，原来的一个库变成了 5 或多个库，原来的一张表变成了 5 或多个表。


工具：
        然后你在写入数据的时候，需要借助数据库中间件，比如 sharding-jdbc，或者是 mycat，都可以。

分表保证查询性能：
        你可以根据比如订单 id 来 hash 后按 5 取模，比如每天订单表新增 50 万数据，此时其中 10 万条数据会落入 db_order_01 库的 tb_order_01 表，另外 10 万条数据会落入 db_order_02 库的 tb_order_02 表，以此类推。
        这样就可以把数据均匀分散在 5 台服务器上了，查询的时候，也可以通过订单 id 来 hash 取模，去对应的服务器上的数据库里，从对应的表里查询那条数据出来即可。

生成全局唯一id方案

1. 独立数据库自增 id
2.UUID
3.时间戳
4.编写算法