架构学习-复杂度来源

SystemDesign 架构

创建时间:2020-02-04 12:09

字数:2k 阅读:

评论:

架构设计的主要目的是为了解决软件系统复杂度带来的问题，那么复杂度的来源到底在哪里呢？

1. 高性能

操作系统 - 是将硬件性能充分发挥出来的关键。

最初是只有输入计算以及输出功能
批处理 - 将要执行的指令预先写下来，形成一个指令清单，然后将任务交给计算机执行，读取任务中的指令清单并进行处理
进程 - 进程对应任务，都有自己的内存空间，进程间互不相关
进程间的通信
- 管道
- 消息队列
- 信号量
- 共享存储
线程
- 进程内部的子任务，都共享同一份进程数据。为保证数据的正确性，有了互斥锁机制。有了多线程以后，操作系统调度的最小单位就变成了线程，而进程变成了操作系统分配资源的最小单位。
多个CPU真正同时执行计算任务
- SMP symmetric multi processor
- NUMA Non uniform memory access
- MPP Massive Parallel Processing

突然发现双十一峰值，支付宝能到每秒12万笔；红包能达到76万。通过大量机器来提升性能，并不仅仅是增加机器这么简单，让多台机器来配合达到高性能的目的，是一个复杂的任务，复杂在于：

系统无中断地执行其功能的能力，代表系统的可用性程度

通过冗余来实现高可用，与高性能的区别在于，高性能增加机器的目的在于扩展处理性能；高可用增加机器的目的在于冗余处理单元

多台服务器时主备的选择，具体采用什么方式，主备分别的个数，结合实际业务需求来分析和判断。

高可用设计的关键点就在于存储高可用了，区别在于将数据从一台机器搬到另一台机器，需要经过线路进行传输

无论是正常情况下的传输延迟，还是异常情况下的传输中断，都会导致系统的数据在某个时间点或者时间段是不一致的，而数据的不一致又会导致业务问题；存储高可用的难点不在于如何备份数据，而在于如何减少或者规避数据不一致对业务造成的影响。

分布式领域的CAP定理，存储高可用性不可能同时满足一致性，可用性，分区容错性，最多满足其中两个，这就要求我们在做架构设计的时候结合业务进行取舍。

无论是计算高可用还是存储高可用，其基础都是状态决策，即系统需要能够判断当前的状态是正常还是异常的，如果出现异常就要采取行动来保证高可用。但一个矛盾点在于：

通过冗余实现的高可用，状态决策本质上就不可能做到完全正确

常见的决策方式：

独裁式
- 只有一个决策者
- n个上报者
- 不会出现决策混乱，但是决策者本身故障的时候，系统就崩了
协商式
- 两个独立的个体通过交流信息，根据规则进行决策
- 主备决策
- 2台服务器启动时都是备机
- 建立连接
- 交换状态信息
- 某1台服务器做出决策，成为主机；另一台继续保持备机身份
- 协商式当连接出问题的时候，采用哪个？两主？多连接？仍然存在问题的
民主式
- 多个独立个体通过投票的方式进行状态决策
- ZooKeeper集群在选举leader时就采用这种方式
- 对于连接断开，可能出现多个leader的问题的解决
  - 投票节点数必须超过系统总结点数的一半的规则

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 stone2paul@gmail.com