knightliao / pikaq Goto Github PK

@knightliao，感谢提供pikaQ组件来实现分布式可靠消息（虽然还没有release)。我的问题是，是否考虑过IMDG的一些技术来达到这个手段（下述是我的一些理解，不足之处请斧正）

1. 以hazelcast为例，其提供了带事务特征的消息队列TransactionQueue，其通过两阶段方式（具体请参考https://github.com/hazelcast/hazelcast-reference-manual/blob/master/src/Transactions/Transactions.md 实现队列操作数据的完整性
2. 就MQ在事务提交过程环节中存在的回滚以及可能引发的脏数据，我的看法是如果TransactionQueue关联的事务环境（通过TransactionContext)如果能够参与当前业务数据的事务，那么应该也可以做到当其事务回滚那么MQ的事务也将回滚，能确保MQ数据不会多（即MQ的事务参与到业务事务中，后者提交成功才能确保MQ事务的提交、而两阶段方式能够确保MQ能一定将数据同步，即业务事务处理成功后）
3. MQ环节记录的消息信息（即待处理）需进行持久化，这个可否考虑berkeley db（其既为嵌入式又支持事务）来替代MYSQL

我的想法(不知是否可行）：

1. 构建围绕IMDG的集群环境，参与集群的机器均集成针对berkeley db的支持
2. 参与分布式可靠消息的应用，均通过客户端API连接到IMDG中。如果A与B系统存在分布式事务的关联，则通过1来进行知会。
3. IMDG的事务提交如transactionContext，可引入针对当前事务的支持（transactionManager)，
   我个人的经验是引入hazelcastmq（内部集成了spring transaction的支持）
4. 当A系统业务处理然后再引入消息队列控制时，如1-3的内部支持可使得A系统业务OK后，产生了需要B系统进行同步处理的消息（并得到持久化)，B系统对接到集群环节中会从相关队列中提取带待同步处理的消息，处理完毕后再更新持久化消息（队列方式则决定当B成功读取消息后会从其移除掉）
   ——如果该环节环节突然处理失败，则重启后仍然会提取到待处理的消息

上面的考虑是考虑引入针对hazelcast等transactionManager支持（看可否不考虑AOP方式）

我看了一下实现代码，消息的持久化要和业务事物域用同一个数据库事物？ 是否可以持久化和rabbitmq抽取出来，这样消息数据独立存储、独立伸缩、降低业务系统与消息系统间的耦合

根据您“基于RMQ的可靠消息系统设计(设计图)”中理解，应该是“pikaQ”会回调业务系统的接口“判断是否业务处理服务”成功，这里面有两个问题：
1、这个接口的判断一般是在消息发送之前（入MQ队列）前发送，还是在消息发送后由消息消费者使用？
2、由于该接口是业务相关的，在“pikaQ”中是否有做封装？我并未从测试用例中找到判断“业务处理服务成功”的逻辑，能否帮忙提供下具体程序位置吗？
另外，我理解按照pikaQ设计，所有的消息都应该存储在一个数据库中，那未来业务量很大的时候，数据库是否会存在瓶颈？
非常感谢！