消费服务首先从Redis里通过BLPOP从orders列表中获取元素，再触发事件总线，执行订单保存相关业务处理。
最终看下执行效率如何？
消息发布的执行效率(订单保存)
消息消费
可以看到目前消息发布的执行效率下单总耗时间为1170毫秒，我们再改为同步的测试下结果：
可以看到，同步执行的结果是3035毫秒。
小结
两种方式相差了将近2000毫秒~ 而且后续如果再继续扩展订单存储相关处理的话同步执行的响应时间会更加拉长，而采取Redis MQ的方式配合事件总线我们可以将整个业务拆分为独立的应用，采取分布式的方式提高响应效率，同时事件总线的加入方便我们后续业务的扩展。
消息发布端将订单信息写入到列表后如果消息消费者在拉取到数据后业务执行过程中代码出现异常导致无法满足业务的完整性如何处理
答:可以使用上述Redis命令中的RPOPLPUSH或BRPOPLPUSH在拉取元素后写入到一个备份的列表中，在我们的逻辑代码执行完毕后在将备份列表中的该元素值移除。
上述代码已发布到Github，有需要的自行下载。
地址为:https://github.com/QQ897878763/OrderRedisSample
