系统并发设计思路

概念

• TPS（Transaction Per Second）每秒处理的事务数。从客户端发起请求开始计时，等到收到服务器端响应结果后结束计时，在计算这个时间段内总共完成的事务个数
• QPS（Queries Per Second）每秒查询数，表示服务器端每秒能够响应的查询次数。这里的查询是指用户发出请求到服务器做出响应成功的次数，可以简单认为每秒钟的Request数量。
• RT（Response Time），表示客户端发起请求到服务端返回的时间间隔，一般表示平均响应时间。
• 并发数是指系统同时能处理的请求数量。如果QPS=1000，表示每秒钟客户端会发起1000个请求到服务端，而如果一个请求的处理耗时是3s，那么意味着总的并发=1000*3=3000，也就是服务端会同时有3000个并发

分析

如果有过往的相似业务交易历史数据经验，你需要尽量参考，处理这些收集到的原始数据（日志），从而分析出高峰时段，以及该时段下的交易行为，交易规模等，得到你想要看清楚的需求细节•另外一种情况，就是没有相关的数据指标作为参考，这个时候就需要经验来分析。比如可以参考一些类似行业的比较成熟的业务交易模型（比如银行业的日常交易活动或交通行业售检票交易活动）或者干脆遵循“2/8”原则和“2/5/8”原则来直接下手实践。

1000W用户，每天来访问这个网站的用户占到20%，也就是每天有200W用户来访问。•假设平均每个用户过来点击50次，那么总共的PV=1亿。•一天是24小时，根据2/8法则，每天大部分用户活跃的时间点集中在(24*0.2) 约等于5个小时以内，而大部分用户指的是（1亿点击 * 80%）约等于8000W（PV）， 意味着在5个小时以内，大概会有8000W点击进来，也就是每秒大约有4500(8000W/5小时)个请求。•4500只是一个平均数字。在这5个小时中，不可能请求是非常平均的，有可能会存在大量的用户集中访问（比如像淘宝这样的网站，日访问峰值的时间点集中在下午14：00、以及晚上21：00，其中21：00是一天中活跃的峰值），一般情况下访问峰值是平均访问请求的3倍到4倍左右（这个是经验值），我们按照4倍来计算。那么在这5个小时内有可能会出现每秒18000个请求的情况。也就是说，问题由原本的支撑1000W用户，变成了一个具体的问题，就是服务器端需要能够支撑每秒18000个请求（QPS=18000）。

JVM中默认情况下在创建新线程时会分配大小为1M的线程栈，所以，更多的线程意味着需要更多的内存。线程数的经验值为：1核2g内存，线程数经验值200；4核8g内存，线程数经验值800