在设计一个高并发系统之前，首先要认识到该系统的复杂度是什么？前文已经说了引起系统复杂度的三高问题，但是当落实到一个具体业务系统上面时，往往是错综复杂的，下面我们从一个案例来详细讲解，这个案例也是我以前遇到的真实案例。
数千万用户级别的跑步APP，5000万跑步用户，早晚高峰期，使用人数较多，用户可以关注其他跑友，读取最新关注好友的动态。跑步完成后记录会自动上传至服务器，并形成一条动态。用户可以发动态消息，包括文字或者图片。
每到早晨和晚上，系统无法处理大量数据请求，数据同步出错，数据库连接池耗尽，数据库服务器的CPU100%占用。
看看这个系统的核心复杂度在哪里。
- 该系统的业务逻辑比较简单，假设每天有1000万用户使用软件跑步一次（这个活跃度已经比较高了），也就是每天有1000万条记录上传，因为跑步活动不是全天24小时的，主要集中在一早一晚，所以我们平均分配到早晚的各3小时，总共6各小时，在这6个小时内，平均分散到每秒上传的记录就是463条，即TPS为463。在考虑一下峰值的情况，一般是平均值的3倍，即1389。在考虑系统的性能冗余，4倍峰值，即最终TPS为5556。
- 该系统每产生一条跑步记录，就会生成一条动态，也就是说每天有1000万条动态记录产生，在加上用户自己发的动态，假设每人每天发送2条动态，也就是总共有3000万条动态产生。参考上面的计算方式，最终TPS为16668。
- 对于浏览所有关注用户动态功能，1000万用户产生的动态记录是3000万条，假设这1000万用户平均粉丝是5个，那么动态记录被消费总次数就是1亿5000万次，参考上面的计算方式，即QPS为83328。
综合来看，系统写压力在于跑步记录上传，和用户动态，即总的TPS为5556+16668=22224；而读取压力在查看关注人的动态记录，即QPS为83328。这个值是对于系统后期性能的冗余估计，这种估计不能一开始估的太高，比如100倍的性能估算，这样不符合实际情况 。
很明显，高性能是必须的，不然后期用户量增大后，无法提供稳定的服务，特别是QPS的要求已经很大了；高可用也是显而易见的，早晚高峰期，用户无法上传跑步记录，会导致用户流失，平台价值递减。而对于扩展性，没有类似秒杀等的突发性活动，对性能的要求也是平滑的，所以扩展性没有要求。
总之，经过对于业务和数据的分析，得出系统复杂度在于高性能的读写和高可用，但是实际要结合团队人员，以及团队技术情况来确定后面的架构方案。