共计 3184 个字符，预计需要花费 8 分钟才能阅读完成。
导语
Apache Pulsar 是一个多租户、高性能的服务间音讯传输解决方案，反对多租户、低延时、读写拆散、跨地区复制、疾速扩容、灵便容错等个性。其原生反对了跨洲际级别的跨地区复制的解决方案，并联合其本身的 Tenant 和 Namespace 级别的形象，能够灵便的反对不多品种，不同场景下的跨地区复制解决方案。
需要背景
目前腾讯公司外部业务在应用 Pulsar 的过程中，综合业务是否是在线影响用户体检，是否产生营收影响，以及在降本增效趋势下的老本思考，会抉择不同级别的容灾策略，上面从业务场景以及保障水平形容 Pulsar 以及客户端的容灾部署和策略配置。
Pulsar 多正本机制以及强一致性
在一致性方面，Pulsar 采纳 Quorum 算法，通过 Write Quorum 和 Ack Quorum 来保障分布式音讯队列的正本数和强统一写入的应答数 (A>W/2)。在性能方面，Pulsar 采纳 Pipeline 形式生产音讯，通过程序写和条带化写入升高磁盘 IO 压力，多种缓存缩小网络申请放慢生产效率。
另一方面，在单个 Bookie 写入数据的时候能够配置强制刷盘写 Journal 即 Wal.
这个 Journals 文件里存储的相当于 BookKeeper 的事务 Log 或者说是写前 Log, 在任何针对 Ledger 的更新产生前，都会先将这个更新的形容信息长久化到这个 Journal 文件中。
Bookeeper 提供有独自的 Sync 线程依据以后 Journal 文件的大小来作 Journal 文件的 Rolling;
写入的 EntryLog 和 Index 都是先缓存在内存中，再依据肯定的条件周期性的 Flush 到磁盘，这就造成了从内存到长久化到磁盘的工夫距离，如果在这距离内 BookKeeper 过程解体，在重启后，咱们须要依据 Journal 文件内容来复原，这个 LastLogMark 就记录了从 Journal 中什么地位开始复原;
经营实际：
所以基于以上两个个性，咱们能够依据 Write Quorum 和 Ack Quorum，以及是否开启写 Journal 和是否同步异步写 Journal 在老本和容灾保障之间做一个适合的配置，目前线上在平安业务在数据量较大的状况下敞开了写 Journal，只有正本保障数据可靠性
机架感知策略
机架感知是 Ensemble Placement Policy（EPP）的一种，是 Bookkeeper Client 用来抉择 Ensemble 的算法，抉择的根据次要是依赖网络拓扑属性。
示例 2：
Region A 和 B 有四个 Bookie，BK1 , BK2 , BK3 and BK4，它们的网络地位是，Region-A/Rack-1/BK1 , /Region-A/Rack-1/BK2 , /Region-B/Rack-2/BK3 和 /Region-B/Rack-2/BK4，网络拓扑构造如下：
root
/ \
region-a region-b
| |
rack-1 rack-2
/ \ / \
bk1 bk2 bk3 bk4
RackawareEnsemblePlacementPolicy 会依赖 Rack 信息来从不同的 Rack 上选取 Bookie，能够保障 Write Quorum 至多包含两个 Rack，这个策略要求网络拓扑中至多蕴含两个 Rack 信息。
经营实际：
在领取和广告场景中部署会将不同网络分区的机器放在不同的 Rack 下面，例如深圳荔景、深圳深宇机器调配在 Rack-1、Rack-2，而后配置正本的 Write Quorum =Ack Quorum，这样当其中一个例如深圳荔景网络机房故障时，业务能持续从深圳深宇生产生产数据，
这里有两点值得注意:
- Zookeeper 也须要跨 3 个可用区部署，至多两个在深圳荔景、深圳深宇;
- 单个网络分区需短暂撑持两倍流量。
跨地区复制 (GEO 模式)
Apache Pulsar 内置了多集群跨地区复制的性能，GEO-Repliaaction 是指把扩散在不同物理地区的集群通过肯定的配置形式让其能在集群之间进行数据的互相复制。
以后领有两个集群，别离部署在北京和上海，当用户在北京的集群中应用 Producer 发送数据时，首先会发送到北京机房的本地集群中（Topic1）与此同时会去创立一个 Replication Cursor，用于专门复制数据的一个游标，通过这个 Cursor 信息，你能够判断以后数据到底复制到哪一个阶段。同时会去创立 Replication Producer，它会把数据从北京机房的 Topic1 中读取数据，而后将数据写到上海机房的 Topic1 中，上海机房的 Broker 收到 Producer 的申请之后，会写到本地雷同的 Topic 中来（Topic1）。此时如果上海机房的用户开启 Consumer 去生产数据的话，会接管到由北京机房 Producer 生产的数据信息。
问题:
- Pulsar 只能保障单机房生产的音讯程序，在多机房的场景下没方法保障多个机房的音讯全局有序；
- 因为 Cursor Snapshot 是定期进行的，在工夫上精确度不会太高，多少有些偏差。
经营实际：
在广告多份场景业务部署了深圳、上海、天津三地集群，配置相互复制，业务个别从深圳写入，上海、天津业务端本地生产，局部场景加工完写回本地集群，很好的解决了多份生产的时延问题。
MQ 经营过程中会发现一个十分辣手的问题是，如果一个业务滞后十分多，哪怕 Pulsar 是读写拆散的，然而因为线程、内存等是共享的，大量的滞后读还是要导致写入时延变高，在非 SDD 盘变现更为显著，这时候就能够用 GEO 模拟出多份数据，做到业务的隔离，让那些不关怀滞后的业务放在 GEO 的一个集群，做到数据隔离。
业务双写，双生产 + 跨地区复制 (GEO 模式)
在 3 中介绍了跨地区复制原理，然而实际应用中业务有更高级别的容灾要求，因为跨地区给地的写入端还是只有一个，如果在写入过程中 Pulsar 集群故障还是会导致业务写入失败，影响在线业务展现甚至影响公司营收，所以业务会采纳双写和双生产，每地部署两个集群。
经营实际：
在广告业务中，部署了两套三地 GEO 集群，在运管过程中，一套因为机器故障，或者业务滞后导致使用不当，实现不会影响业务的应用，这个过程业务写入尽管能够失败，然而生产端确是须要去重。
计费场景的版本及部署
计费场景为什么须要独自探讨呢，因为同 4 广告场景相比，广告计费链路业务场景的计费个性强依赖音讯队列，不能跨城实时双写，防止曝光申请反复计费。而且计费业务须要每条音讯都须要生产生产溯源，在对账对不齐时，须要找到在那个过程中数据异样（没生产，数据失落）了, 所以在计费版本 Pulsar 后面退出无状态的生产生产代理 Proxy，各地会部署两套以上集群, 在 Proxy 后面加上公司的 l5, 如果某个 Pulsar 集群故障将 l5 中的节点敞开。
经营实际：
目前计费业务理论中如上图部署，当集群故障时，将 l5 中集群节点屏蔽，未生产的数据待集群复原时补录数据，同时有 Tools 工具将数据备份到本地。
将来布局
从下面 4 中咱们能够看到，目前须要业务双写双生产解决故障过程中集群应用，会带来几个问题：
- 业务须要保障事务，上游须要去重;
- 双写双生产业务客户端老本加倍.
平台侧优化：
能不能所有容灾都让 pulsar 承当，业务只是应用方齐全不须要理睬容灾等，这是将来平台侧一个微小的挑战
目前的一个比拟清晰的计划大抵是服务端侧通过 GEO 将数据和生产 Cursor 在两个集群同步，同时 SDK 须要反对多个 Pulsar 集群地址的切换，目前在 2.10 版本曾经反对生产端 SDK 多集群配置，然而生产端还不反对，而且 GEO 的数据同步和生产位点 Cursor 同步的生效性得也有待增强, 这些将在新版本实现。