读发布！设计与部署稳定的分布式系统（第2版）笔记08_自黑与放大.png

1. 自黑式攻击

1.1. 自黑只会偶尔成为人类的美德

1.2. 对系统来说，绝对不会推崇自黑

1.3. “自黑式攻击”是指系统或有人类参与的扩展系统联合外部对自身发起攻击

1.4. 好的营销可以随时杀死你

1.4.1. 并不是每个自黑的“伤口”，都可以归咎于营销部门

1.5. 典型例子

1.5.1. 公司市场部发出的致“精选用户组”的一份邮件

1.5.2. 该邮件包含一些特权或优惠信息，其复制速度比木马病毒快得多

1.5.3. 定价错误使得一个SKU的订购次数等于其他所有产品的订购总数

1.5.4. 在基于ATG的基础设施中，锁管理器总是会处理分布式锁管理，以确保缓存的一致性

1.5.4.1. 锁管理器资源只有一个，随着网站横向扩展，锁管理器会成为瓶颈，并且最终会成为风险

1.5.4.2. 如果一个热门项目被无意修改，最终就可能会导致数以百计的服务器上出现数千个请求处理的线程，都在排队等待该项目的写入锁

2. 共享资源

2.1. 以面向服务的架构或“公共服务”项目为幌子，共享资源会成为水平扩展层级所有成员都需要使用的某个设施

2.2. 可以是集群管理器或锁管理器

2.3. 当共享资源流量过载时，它会成为限制系统容量的瓶颈

2.4. 当共享资源有冗余且是非独占的时，就没有问题

2.4.1. 可以同时为多个消费者提供服务

2.5. 最具扩展性的架构是无共享架构

2.5.1. 在无共享架构中，系统容量与服务器的数量几乎呈线性关系

2.5.2. 无共享架构的问题在于，它会牺牲故障转移来获得更好的扩展性

2.5.3. 通过减少共享资源的扇入个数，可以近似实现无共享架构，即减少调用共享资源的服务器

3. 避免自黑式攻击

3.1. 构建无共享架构

3.1.1. 在无共享架构中，每台服务器在不知道任何其他服务器的情况下，仍然能够运行

3.1.2. 服务器不共享数据库、集群管理器或任何其他资源，这是水平扩展的理想状态

3.1.3. 通过中间件模式减少过量请求造成的影响，或尽量通过冗余和后端同步协议，实现共享资源本身的水平扩展

3.1.4. 当共享资源不可用或没有响应时，还可以为系统设计一个后备模式

3.1.5. 如果提供悲观锁的锁管理器不可用，那么应用程序可以进入后备模式并使用乐观锁

3.2. 保护共享资源

3.2.1. 当流量激增时，编程错误、意外的放大效应和共享资源都会产生风险

3.2.2. 前端负载的增加，会导致后端处理量呈指数级增长

3.3. 预留一部分基础设施，或整备一些新的云资源，用于应对商业促销或流量激增

3.4. 当访问流量激增时，可以使用自动化扩展技术

3.4.1. 注意服务器启动的延迟时间

3.5. 保持沟通渠道畅通

3.5.1. 应对人为的攻击，关键在于培训、教育和沟通

3.6. 快速地重新分配实惠的优惠

3.6.1. 任何一个认为能限量发布特惠商品的人，都在自找麻烦

3.6.2. 根本就没有限量分配这回事

3.6.3. 即使限制了一个超划算的特惠商品可以购买的次数，系统仍然会崩溃

4. 放大效应

4.1. 生物学中的平方-立方定律

4.1.1. 虫子的重量随着体积增加而增加，符合时间复杂度O(n^3)

4.1.2. 虫子的腿部力量会随腿的横截面积的增加而增加，符合时间复杂度O(n^2)

4.1.3. 如果让虫子增大为原来的10倍，那么变大后的虫子的“力量与体重”之比就会变成原来的1/10

4.1.4. 虫子的腿根本支撑不了10倍大的个头

4.2. “多对一”或“多对少”的关系

4.2.1. 如果这个关系中一方的规模增大，另一方就会受到放大效应的影响

4.2.2. 由于开发环境和测试环境的规模很少会与生产环境一致，因此很难在前两个环境中，看到放大效应跳出来“咬人”

4.2.3. 1台数据库服务器被10台机器调用时，可以很好地运行

4.2.4. 调用它的机器数量再额外添加50台时，数据库服务器就可能会崩溃

5. 点对点通信

5.1. 放大效应“咬人最凶”的情况

5.2. 当只有一两个实例进行通信时，机器之间的点对点通信可能工作得很好

5.3. 每个实例必须直接与其他实例进行沟通，连接的总数，会以实例数量平方的数量级上升

5.4. 连接数会扩展到时间复杂度O(n^2)

5.5. 务必将单个服务内的点对点通信，与服务之间的点对点通信区分开

5.6. 除非是微软或谷歌这样的公司，其他公司不可能构建与生产环境相同大小的测试农场

5.6.1. 这种类型的软件缺陷是不可能被测试出来的，必须通过设计来避免

5.6.2. 参照测试环境检查生产环境，以发现放大效应

5.7. 替换方式

5.7.1. UDP广播

5.7.1.1. 广播能够应对服务器数量的不断增长，但它不节省带宽

5.7.1.2. 与广播消息不相关的服务器产生一些额外的负载

5.7.2. TCP或UDP组播

5.7.2.1. 只允许相关的服务器接收消息，传送效率更高

5.7.3. 发布-订阅消息传递

5.7.3.1. 服务器在消息发送的那一刻没有监听，也可以收到消息

5.7.3.2. 传递的效率也较高

5.7.3.3. 通常会让基础设施成本大增

5.7.4. 消息队列

5.7.5. 在所有可行的方案中，选择最简单的那个来做