缘起

面试经常会遇到问题

1. 刚才说的这个系统并发是多少
2. 你们系统数据量是多少

或者工作中你会遇到：

1. 产品经理问你：咱们这个系统对机器有啥要求，宽度给多少合适
2. 项目经理给你任务：帮咱们盘点一下机器，把没用的机器回收了吧
3. 双十一咱们系统能抗住不，需要增加几台机器，机器规格发我

限制因素

包括：CPU，内存，磁盘读写速度，操作系统对进程中的线程的数量限制， 带宽，一个请求的数量大小，中间件支持的并发量。

评估办法

• 并发量最开始评估，有并发量*平均数据量就是我数据量总量
• 并发量按照点击率预估：如果有特定场景，比如：广告推送1kW，大概有1%的点击率，那么广告的PV就是1KW*1%=10W 总量；
• 并发按照场景评估：如果业务系统，一次工单提交需要10次请求HTTP，那么乘以每天平均的工单梳理就是一天的并发数量
• 时间，每天是8W秒，但一般都发生在白天就按照4W秒来算，总量/4WS=平均QPS
• 峰值QPS：如果统计的数据就按照峰值是平均几倍来算。否则按照28原则(80%的请求发生在20%的时间范围内) 算出峰值QPS
• 数据量评估：统计或者预估，按照业务限制能提交的文件和数据量，完成一个业务平均的数据量，乘以平均QPS就是数据总量
• 带宽：数据总量除以时间就是数据带宽，网络带宽必须大于这个。同时也需要根据峰值QPS计算峰值带宽
• 中间件并发量分析：Mysql，Tomcat，Nginx，Redis，MQ，ZK等不同中间件能支持的并发量是不同的，后面挨个说明
• 中间件并发量不一定等于线程数量，需要根据中间件机制判断，比如redis就是单线程的，但也能支持10W的并发，tomcat中servlet是多线程的，一个请求用一个线程处理，那么就需要考虑线程的限制了。
• 不同操作系统对线程限制不同，比如：linux默认给一个进程1024个线程，再多就需要修改配置。
• 磁盘大小，如果是WEB需要考虑日志量；如果是DB或者文件服务器机器 需要考虑文件总量增量
• 磁盘读写速度 自建的话这个需要压测
• 内存大小跟业务有关系，大批量计算类型的业务系统就比较耗内存；但高并发的抢票的系统，支持并发量就更重要了。

特例支持

• 读写不平衡. 读多写少 场景: 缓存，读写分离
• 读写不平衡. 写多读少 场景: 看业务可以使用ISAM引擎，或者使用redis
• 计算型场景：并发少，特别消耗内存； 异步方案，比如：生成报表功能，拆分为：提交生成报表请求， 处理状态查询， 处理 这么几步
• 并发在时间维度上不平衡 场景： 秒杀场景，短时间内高 并发，使用MQ削峰填谷
• 缓存的同步机制：Mysql主从用Mysql同步机制，或者用binlog同步。 业务缓存跟业务关联较大，可用方案如：binlog+MQ同步；手动同步等； redis，rocketmq 缓存内容的数据，持久化策略问题

END