共计 1537 个字符，预计需要花费 4 分钟才能阅读完成。
当下所有的利用零碎都是数据密集型，不是计算密集型，零碎瓶颈不是因为 CPU 算力有余，而是因为大数据量带来的数据存储，数据计算，数据同步以及数据更新带来的一系列问题，具体表现形式有以下几种，比方 redis 和数据库的双写一致性问题，音讯积压问题，redis 集群或者 MySQL 集群中主从节点的数据同步问题，以及 redis 长久化问题。包含对于程序员来讲最大的并发同步问题实际上就是短时间内的大量数据计算，存储以及更新问题。
目前所有的系统结构设计都有如下的功能模块
- 数据长久化模块，保留咱们的数据用于记录然而的零碎状态，罕用就是数据库，比方 MySQL，MongoDB 等数据库
- 缓存模块，记录低廉的零碎耗费的后果，用来升高零碎压力放慢下一次的读取速度。比方 redis，RocksDB 等内存数据库。
- 搜寻模块，用户能够通过关键字进行搜寻以及对数据按须要进行过滤，常见的就是 ES 流解决，给其余进行进行发消息进行异步解决，缩小零碎压力，进步零碎响应工夫。比方常见的消息中间件 MQ
批处理，用于定时进行数据同步，比方咱们罕用的脚本和定时工作。
redis，rocketMQ 等各种中间件都有本人的独特的应用场景的特点，只能高效实现某种特定性能 (比方 redis 重要就是用做换缓存，MQ 根本都是用来异步，解耦，削峰，过后目前 MQ 都开始反对事务音讯以保障对分布式事务进行反对和弥补) 咱们利用代码就是将各种中间件进行缝合成一个整体，同时保证数据在这些中间件中流转的正确性。- 当零碎呈现问题时如何保证数据的正确性和完整性
- 当零碎面临微小压力呈现降级如何保障用户仍然有良好的体验
- 当零碎进行扩容时如何保证数据的正确性和完整性
当下零碎的重要考量点，可靠性，可伸缩性，可维护性
- 可靠性
程序失常应用下提供给用户须要的性能
在超出预期负载和数据量下性能满足要求
零碎可能无效拦挡未经受权的拜访
总结就是零碎呈现故障仍然可能持续为用户提供服务。然而故障不等于生效。对于利用层面的代码而言，咱们在日常业务实现和代码编写过程中的注意事项就是
防止死锁耗费 CPU，内存等公共资源而升高整体零碎性能。
级联故障，应用服务依赖的根底服务出现异常时导致服务不可用或者根底服务报错间接展示给用户。可伸缩性
咱们的零碎为随着工夫的减少，用户量和数据量也会同步减少。在负载减少的同时如何保证系统仍然可用就是可伸缩性。- 负载考量
咱们每个零碎的设计和实现都是针对特定的应用场景和应用人群，所以在形容零碎负载时不同的零碎就用不同的角度来进行。比方有的是统计每秒向服务器收回的申请数，数据库每秒解决的事务量，缓存命中率，零碎在线沉闷用户量。有工夫咱们解决一个申请会申请很多其余服务，就会呈现微小的扇出刹时的零碎负载会十分高，有时候这种申请会耗费很多零碎性能。这种扇出有时候能够作为特定场景下的零碎负载参数。(扇出就是说当咱们为了实现一个申请而收回了很多申请去调用其余服务，尽管咱们看似只解决了一个申请，然而听过近程调用也产生了很多申请，比方咱们淘宝或者支付宝或每年都会统计你过来一年的生产记录进行汇总展现，这个申请实际上就是一个微小扇出)
- 性能形容
对于在线零碎，咱们次要考量的就是响应工夫 (response time)，然而同样的申请每次申请服务的响应工夫可能不一样，有时候会受到网络丢包，垃圾回收暂停，线程上下文切换，内存页切换等的影响。有时候响应工夫最长的用户有可能就是最初价值的客户，在失常状况来看，响应工夫越长解决数据多，客户价值就越大。
有时候还会呈现头部阻塞景象，因为服务器 CPU 数量无限，只能并行处理一定量的事务，只有有大量申请阻塞就能妨碍前面的申请解决导致前面所有客户端的响应工夫变长。有时候当一个申请须要多个后端申请时那么这个申请的响应工夫就成了最慢的申请响应工夫。
