分布式杂谈

Tags:

分布式中心化/去中心化

既然分布式了为什么还有中心化？其中关键是简化了中心节点的任务，中心节点是作为任务派发者、网络管理者存在的，类似领导和员工的关系。

领导节点可能是所有节点一起选举出来的，而不是固定的。从而避免领导节点故障导致整个网络崩溃。

例子是raft算法。

分布式一致性

一致性是指所有节点的数据状态一致。一般是用来做大型数据库的多机备份和海量服务。多机备份使得单个数据库节点坏了，还有别的数据库可用，数据不易丢失；海量服务是指，既然可以保证多个数据库节点是一致的，那么数据库节点越多，能服务于用户的能力越强，因为用户可以任意选择一个节点存取数据。

分布式一致性算法：paxos、raft。

因为节点之间的同步存在网络延迟，故一致性要分强弱：

  • 强一致：强调读操作读到的肯定是最新的值，即写操作同步到整个网络前，读操作是要阻塞的。
  • 弱一致：单机写入后，不保证其他节点可以立即读到最新的值，也不保证多久之后数据能够达到一致，只是尽可能保证某个时间级别后（秒），能够一致。
  • 最终一致：弱一致的特例，保证会在一定时间内，能够达到一致。

CAP理论

Consistency一致性、Availability可用性、Partition tolerance分区容错性。

  • 数据一致性（C），等同于所有节点访问同一份最新的数据副本；
  • 对数据更新具备高可用性（A）；
  • 能容忍网络分区（P）。

CAP不能同时做到。

只可能做到CP或AP或CA。

  • CA：只有一个数据中心，没有分区，保证节点之间通讯可靠；单机数据库。
  • CP：有多个数据中心时，放弃可用性，强调一致性（不常见）
  • AP：有多个数据中心时，放弃一致性，强调可用性（常见）

BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。

源于CAP。

BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

1、基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。比如：

  • 响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒

  • 系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

2、软状态

软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

3、最终一致性

最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

消息队列

我见过的游戏后端是不存在什么消息队列的。这个东西更多是在互联网产品后端才会出现。但我觉得游戏后端也是能用上的，关键在于游戏需求。

没有消息队列前的问题：

  • 在高并发分布式环境下，大量请求都同步处理的话，请求往往会阻塞。例如大量insert、update操作同时到达mysql，触发各种行锁、表锁，如果请求增加速度大于处理速度，还会不断堆积，触发too many connection错误。
  • RPC（远程过程调用），服务和服务之间高度耦合是个问题。

有了消息队列后：

  • 大量请求先放进消息队列，异步处理，缓解系统压力。
  • MQ提供了松耦合的应用架构。任何一个应用对MQ的调用不依赖于任何其他应用，甚至没有时序要求。但应用依赖MQ保证消息传递的能力。触发和忘记（fire-and-forget)：应用发送消息到MQ后并不关心消息如何或者什么时候被传递，同样的，消息接收者也不关心消息从何而来。这样就允许不同语言相互通信。

分布式缓存

LFU

Least Frequently Used（LFU），如果一个数据在最近一段时间内使用次数很少，那么在将来一段时间内被使用的可能性也很小。

LRU

Least Recently Used（LRU），如果一个数据在最近一段时间没有被访问到，那么在将来它被访问的可能性也很小。

分布式锁

节点互访：RPC

功能：

  • 远程调用
  • 服务注册
  • 服务发现
  • 服务监控

最基础的：

  • 稳定
  • 高性能
  • 多语言

微服务

对象序列化技术

最普通的：JSON

更高级的：MessagePack、Protocol Buffers、FlatBuffers。

分布式数据库拆分

先垂直拆分：不同服务的数据(库)要相互隔离，不要放一起。

后水平拆分：隔离后，单机数据库如果遇到瓶颈，就拆成多机（分片）。

水平拆分会遇到问题：没有一个唯一的入口，来操作数据库。

解决方案：

  • 客户端来实现数据路由：客户端自己决定连接哪个数据库节点，存什么数据。缺点是
  • 中间件：把多机数据库封装成单机的使用方法，客户端操作起来和单机一样，简单很多

参考资料

https://www.cnblogs.com/szlbm/p/5588543.html

https://blog.csdn.net/zfrong/article/details/3372106

(未经授权禁止转载)
Written on July 13, 2018

写作不易，您的支持是我写作的动力！