高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指通过设计保证系统能够同时并行处理很多请求。
1. 性能指标
1.1 QPS，每秒查询
QPS：Queries Per Second 意思是“每秒查询率”，是一台服务器每秒能够处理的查询次数。
用户发起查询请求到服务器做出响应这算一次，一秒内用户完成了50次查询请求，那此时服务器QPS就是50。
1.2 TPS，每秒事务
TPS：是TransactionsPerSecond的缩写，服务器每秒处理的事务数。一个事物是用户发起查询请求到服务器做出响应这算一次。
访问 ‘order.html’ 这个页面,是一个TPS。而order.html’ 页面可能请求了3次服务器（如调用了css、js、order接口），这实际就算产生了三个QPS。
1.3 RT，响应时间
响应时间，一般取平均响应时间，处理一次请求所需要的平均处理时间，它的数值大小直接反应了系统的快慢。
一般系统RT 100ms 以内是比较正常的，300ms 勉强可以接受，1s的话再加上一些其他的外因，给用户的体验就是实实在在的不爽了。
1.4 并发数
并发数是指系统同时能处理的请求数量，一般通过线程和CPU核数来决定，并发数反应了系统的负载能力
1.5 吞吐量
系统的吞吐量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个request 对CPU消耗越高，外部系统接口、IO速度越慢，系统吞吐能力越低，反之越高。
系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间。
- QPS（TPS）：（Query Per Second）每秒钟request/事务 数量
- 并发数： 并发数是指系统同时能处理的请求数量，一般通过线程和CPU核数来决定，并发数反应了系统的负载能力
- 响应时间： 一般取请求的平均响应时间
1.6 计算公式
QPS = 并发量 / 平均响应时间
0.5s 的处理时间，我们至少需要 500 的并发量，才能达到 1000qps
0.1s 的话，因为处理时间变快了，所以现在只需要 100 的并发量，就可以轻松达到 1000qps 的能力了
如果并发量还是 500，我们的 qps 甚至能到 5000
2. 设计高并发系统
2.1 系统拆分
将一个系统拆分为多个子系统，用 dubbo 来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，不也可以扛高并发么。
2.2 缓存
大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家 redis 轻轻松松单机几万的并发。所以你可以考虑考虑你的项目里，那些承载主要请求的读场景，怎么用缓存来抗高并发。
2.3 MQ
比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，疯了。那高并发绝对搞挂你的系统。
用 MQ 吧，大量的写请求灌入 MQ 里，排队慢慢玩儿，后边系统消费后慢慢写，控制在 mysql 承载范围之内如何用 MQ 来异步写，提升并发性。MQ 单机抗几万并发也是 ok 的。
2.4 分库分表
分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就将一个数据库拆分为多个库，多个库来扛更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高 sql 跑的性能。
2.5 读写分离
读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。
2.6 ElasticSearch
es 是分布式的，可以随便扩容，分布式天然就可以支撑高并发，因为动不动就可以扩容加机器来扛更高的并发。那么一些比较简单的查询、统计类的操作，可以考虑用 es 来承载，还有一些全文搜索类的操作，也可以考虑用 es 来承载。
