配置中心调研
一、调研
cloudflare
原文链接
building-with-workers-kv
rocksdb-memory-use
internet-scale
workers-kv
quicksilver
Cloudflare 的网络在峰值时每秒为世界各地的互联网用户处理超过 1400 万个 HTTP 请求。 每次用户对其 DNS 进行更改或对其配置进行数百项其他更改中的任何一项时，都会将该更改分发到90 个国家/地区的 200 个城市。 在几秒钟内就能做到.Quicksilver 每天平均支持 2.5 万亿次读取，平均延迟以微秒为单位
将Kyoto-Tycoon (KT)大规模部署到数千个节点上
每个 DNS 或 HTTP 请求都会向 KT 存储发送多个请求，并且每次 TLS 握手都会从中加载证书。 如果 KT 宕机，许多服务就会宕机，如果 KT 运行缓慢，许多服务也会运行缓慢，写入增加时，写入需要获取刷盘时，导致读性能accept获取锁的时候阻塞，性能下降，随后关闭了fsync,出现数据损坏需要通过修复工具修复。
LMDB 还允许多个进程同时访问同一数据存储 使用mmap以页位操作单位
数千个 LMDB 实例，节点将查询主节点，而主节点又会查询顶级主节点以获取最新更新
数千台服务器上的 90,000 多个数据库实例上服务超过 2.5 万亿个读取请求和 3000 万个写入请求
- 开发 Quicksilver 的分片版本。 这将避免在所有机器上存储所有数据，但保证整个数据集位于每个数据中心。
- 与 LMDB 相比，RocksDB 可以在 40% 的空间中存储相同的数据。 在某些情况下，读取延迟会稍高一些，但并不是太严重。 CPU 使用率也更高，使用了大约 150% 的 CPU 时间，而 LMDB 则为 70%。
- 构建了一个名为“QSusage”的服务，它使用 QSrest ACL 将 KV 与其所有者进行匹配，并计算每个生产者使用的总磁盘空间，包括 Quicksilver 元数据。 这项服务能够更好地了解他们的使用情况和增长速度。
- 构建了一个服务名称“QSanalytics”来了解“我如何知道哪些 KV 对从未使用过？。 它收集通过 Cloudflare 访问的所有key，聚合这些key并将它们推送到 ClickHouse 集群中，在 30 天的滚动窗口中存储这些信息。 这里没有采样，跟踪所有读取访问。 可以轻松地向负责未使用密钥的工程团队报告，他们可以考虑是否可以删除这些密钥或必须保留这些密钥。
Apollo
Config Service 提供配置的读取、推送等功能，服务对象是 Apollo 客户端
Admin Service 提供配置的修改、发布等功能，服务对象是 Apollo Portal（管理界面）
Config Service 和 Admin Service 都是多实例、无状态部署，所以需要将自己注册到 Eureka 中并保持心跳
在 Eureka 之上我们架了一层 Meta Server 用于封装 Eureka 的服务发现接口
Client 通过域名访问 Meta Server 获取 Config Service 服务列表（IP+Port），而后直接通过 IP+Port 访问服务，同时在 Client 侧会做 load balance、错误重试
Portal 通过域名访问 Meta Server 获取 Admin Service 服务列表（IP+Port），而后直接通过 IP+Port 访问服务，同时在 Portal 侧会做 load balance、错误重试
为了简化部署， Config Service、Eureka 和 Meta Server 三个逻辑角色部署在同一个 JVM 进程中
携程出海，多数据中心同步
开源 | 携程Redis多数据中心解决方案-XPipe (qq.com)
有了keeper之后，多数据中心之间的数据传输，可以通过keeper进行。keeper将Redis日志数据缓存到磁盘，这样，可以缓存大量的日志数据(Redis将数据缓存到内存ring buffer，容量有限)，当数据中心之间的网络出现较长时间异常时仍然可以续传日志数据。
Redis协议不可更改，而keeper之间的数据传输协议却可以自定义。这样就可以进行压缩，以提升系统性能，节约传输成本；多个机房之间的数据传输往往需要通过公网进行，这样数据的安全性变得极为重要，keeper之间的数据传输也可以加密，提升安全性。
任何系统都可能会挂掉，如果keeper挂掉，多数据中心之间的数据传输可能会中断，为了解决这个问题，需要保证keeper的高可用。我们的方案中，keeper有主备两个节点，备节点实时从主节点复制数据，当主节点挂掉后，备节点会被提升为主节点，代替主节点进行服务。
提升的操作需要通过第三方节点进行，我们把它称之为MetaServer，主要负责keeper状态的转化以及机房内部元信息的存储。同时MetaServer也要做到高可用：每个MetaServer负责特定的Redis集群，当有MetaServer节点挂掉时，其负责的Redis集群将由其它节点接替；如果整个集群中有新的节点接入，则会自动进行一次负载均衡，将部分集群移交到此新节点。
DR切换分为两种可能，一种是机房真的挂了或者出异常，需要进行切换，另外一种是机房仍然健康，但是由于演练、业务要求等原因仍然需要切换到另外的机房。XPipe处理机房切换的流程如下：
- 检查是否可以进行DR切换类似于2PC协议，首先进行prepare，保证流程能顺利进行。
- 原主机房master禁止写入此步骤，保证在迁移的过程中，只有一个master，解决在迁移过程中可能存在的数据丢失情况。
- 提升新主机房master
- 其它机房向新主机房同步
当然了，即使做了检查，也无法绝对保证整个迁移过程肯定能够成功，为此，我们提供回滚和重试功能。回滚功能可以回滚到初始的状态，重试功能可以在DBA人工介入的前提下，修复异常条件，继续进行切换。
评论 (0)