PhxQueue 目前在微信内部广泛支持微信支付、公众平台等多个重要业务，日均入队达千亿，分钟入队峰值达一亿。
其设计出发点是高数据可靠性，且不失高可用和高吞吐，同时支持多种常见队列特性。
PhxQueue支持的特性如下：
-
同步刷盘，入队数据绝对不丢，自带内部实时对账
-
出入队严格有序
-
多订阅
-
出队限速
-
出队重放
-
所有模块均可平行扩展
-
存储层批量刷盘、同步，保证高吞吐
-
存储层支持同城多中心部署
-
存储层自动容灾/接入均衡
-
消费者自动容灾/负载均衡
PhxQueue 设计
整体架构
PhxQueue 由下列5个模块组成。
Store - 队列存储
Store 作为队列存储，引入了 PhxPaxos 库，以 Paxos 协议作副本同步。只要多数派节点正常工作及互联，即可提供线性一致性读写服务。
为了提高数据可靠性，同步刷盘作为默认开启特性，且性能不亚于异步刷盘。
在可用性方面，Store 内有多个独立的 paxos group，每个 paxos group 仅 master 提供读写服务，平时 master 动态均匀分布在 Store 内各节点，均衡接入压力，节点出灾时自动切换 master 到其它可用节点。
Producer - 生产者
Producer 作为消息生产者，根据 key 决定消息存储路由。相同 key 的消息默认路由到同一个队列中，保证出队顺序与入队顺序一致。
Consumer - 消费者
Consumer 作为消费者，以批量拉取的方式从 Store 拉消息，支持多协程方式批量处理消息。
Consumer 以服务框架的形式提供服务，使用者以实现回调的方式，根据不同主题（Topic），不同处理类型（Handler）定义具体的消息处理逻辑。
Scheduler - 消费者管理器（可选择部署）
Scheduler 的作用是，收集 Consumer 全局负载信息, 对 Consumer 做容灾和负载均衡。当使用者没有这方面的需求时，可以省略部署 Scheduler，此时各 Consumer 根据配置权重决定与队列的处理关系。
部署 Scheduler 后，Scheduler leader 与所有 Conusmer 维持心跳，在收集 Consumer 的负载信息的同时，反向调整 Consumer 与队列的处理关系。
当 Scheduler leader 宕机了后，Scheduler 依赖下述分布式锁服务选举出新 leader，不可用期间仅影响 Consumer 的容灾和负载均衡，不影响 Consumer 的正常消费。
Lock - 分布式锁（可选择部署）
Lock 是一个分布式锁，其接口设计非常通用化，使用者可以选择将 Lock 独立部署，提供通用分布式锁服务。
Lock 在 PhxQueue 中的作用有如下两点：
-
为 Scheduler 选举 leader；
-
防止多个 Consumer 同时处理一条队列。
Lock 同样也是可选择部署的模块：
-
若部署了 Scheduler，就必须部署 Lock 为 Scheduler 选举出 leader；
-
否则，若业务对重复消费不敏感，可选择不部署 Lock。
这里所指的重复消费场景是：若省略部署 Scheduler 的话，Consumer 需要通过读取配置得知可处理的队列集合；当队列有变更（如队列缩扩容）时，各 Consumer 机器上的配置改变有先有后，这时各 Consumer 在同一时间看到的配置状态可能不一样，导致一段时间内两个 Consumer 都认为自己该消费同一个队列，造成重复消费。Lock 的部署可以避免该场景下的重复消费。（注意，即使省略部署 Lock，该场景仅造成重复消费，而不会造成乱序消费）。
-
1.测试结果表格里面的kafka同步刷盘和异步刷盘，我认为不准确，会误导用户，因为同步刷盘意味着log.flush.interval.messages=1.而我的理解是文中想表达的是kafka消息同步复制和消息异步复制，即acks=-1和acks=1。因为producer的send()已经是异步发送消息了。 入队 QPS(w/s) 平均耗时(ms) PhxQueue(同步刷盘) 18 90 Kaf
-
简介 PhxQueue的配置分为两类：队列配置和服务器配置。队列配置控制队列的整体参数，需要在所有服务器上部署且保证内容一致，默认实现的队列配置采用json格式。服务器配置只在相应的模块机器上部署，控制当前服务器的特殊参数。 1. 队列配置 1.1 队列Global配置 队列Global配置设定队列的总体参数，文件路径为etc/globalconfig.conf。 topic_infos根配置项为
-
Paxos简介 Paxos 算法解决的问题是一个分布式系统如何就某个值（决议）达成一致。一个典型的场景是，在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列，需要在每一条指令上执行一个"一致性算法"以保证每个节点看到的指令一致。一个通用的一致性算法可以应用在许多场景中，是分布式计算中的重要问题。 Pa
-
本文向大家介绍ZAB 协议和Paxos 算法相关面试题，主要包含被问及ZAB 协议和Paxos 算法时的应答技巧和注意事项，需要的朋友参考一下 Paxos 算法应该可以说是 ZooKeeper 的灵魂了。但是，ZooKeeper 并没有完全采用 Paxos算法 ，而是使用 ZAB 协议作为其保证数据一致性的核心算法。另外，在ZooKeeper的官方文档中也指出，ZAB协议并不像 Paxos 算法那
-
在这种类型的协议中，任何事务在获取适当的锁之前都无法读取或写入数据。 锁有两种类型： 1.共享锁： 它也称为只读锁。 在共享锁中，数据项只能由事务读取。 它可以在事务之间共享，因为当事务持有锁时，它无法更新数据项上的数据。 2.独占锁： 在独占锁中，数据项既可以是读取，也可以是事务写入。 这种锁是独占的，在此锁中，多个事务不会同时修改相同的数据。 有四种类型的锁定协议可用： 1. 简单的锁定协议
-
验证阶段也称为乐观并发控制技术。 在基于验证的协议中，事务在以下三个阶段中执行： 读阶段 ：在此阶段，读取并执行事务T。它用于读取各种数据项的值并将它们存储在临时局部变量中。 它可以对临时变量执行所有写操作，而无需更新实际数据库。 验证阶段 ：在此阶段，将根据实际数据验证临时变量值，以查看它是否违反了可串行性。 写入阶段 ：如果验证了事务的验证，则将临时结果写入数据库或系统，否则将回滚事务。 这里
-
使用 Netty 时会遇到需要解码以分隔符和长度为基础的协议，本节讲解Netty 如何解码这些协议。 分隔符协议 经常需要处理分隔符协议或创建基于它们的协议，例如SMTP、POP3、IMAP、Telnet等等。Netty 附带的解码器可以很容易的提取一些序列分隔： Table 8.5 Decoders for handling delimited and length-based protocol
-
主要内容：本节引言：,1.服务端实现步骤：,2.客户端实现步骤：,本节小结：本节引言： 本节给大家带来Socket的最后一节：基于UDP协议的Socket通信，在第一节中我们已经详细地 比较了两者的区别，TCP和UDP最大的区别在于是否需要客户端与服务端建立连接后才能进行 数据传输，如果你学了前两节TCP的，传输前先开服务端，accept，等客户端接入，然后获得 客户端socket然后进行IO操作，而UDP则不用，UDP以数据报作为数据的传输载体，在进行传输时 首先要把传
-
有没有更好的方法/工具/框架来做到这一点？
-
主要内容：本节引言：,1.运行效果图：,2.实现流程图：,3.代码示例：,4.代码下载：,5.本节小结：本节引言： 上节中我们给大家接触了Socket的一些基本概念以及使用方法，然后写了一个小猪简易聊天室的 Demo，相信大家对Socket有了初步的掌握，本节我们来学习下使用Socket来实现大文件的断点续传！ 这里讲解的是别人写好的一个Socket上传大文件的例子，不要求我们自己可以写出来，需要的时候会用 就好！ 1.运行效果图： 1.先把我们编写好的Socket服务端运行起来： 2.将一个音