这个组件，是一个分布式的组件，好处就是，不怕消息太多了，都挤在一个服务器上，出现服务器内存不够的情况。服务器内存不够用的问题解决了，但是如果消费队列要进行数据库的操作，那么性能瓶颈将出现在数据库上，如果处理的业务复杂，就涉及到分布式事务了，所以一说到分布式，那真的，各种组件，各种复杂。
按我目前的水平，能想到的数据库处理方案，业务之间水平分离，单个业务拿台服务器，这样不用所有业务都挤在一台数据库上，然后不同业务之间靠接口交互，我感觉我说的很像现在的微服务。
还有什么主从同步，读写分离，大概就是把主数据库的数据同步到从数据库，然后从数据库只能被查询，主数据能被增删改，这样做 增删改和查询就不在一个数据库里。但这里我觉得，同步数据超过了主从同步的能力，就会有同步延时的情况，这个又需要解决，所以真的麻烦。
还有分库，分表的做法，因为表的数据太多，查询就会很慢，所以可以分表，具体怎么分，找个什么字段做标识，来分。分库，是把不同的业务拆分到不同的服务器上的数据库里。
这个组件，是如何做到在把队列服务部署到不同服务器上，相互之间还能通信的呢?
会有一个配置，记录应用名称和ip端口号和服务器名，和一个服务器之间的通信路由配置。应用发送的消息得带上目标应用名，也就是接受方的应用名称，就靠这个应用名按算法去配置里找到消息发送到哪台服务器上。
通信有靠tcp/ip协议，和套接字技术，开个线程在后台接受连接的应用程序。
使用Queue做队列容器，开个线程在后台当消息泵，源源不断的出队和入队，并触发响应的事件通知上层发送这个消息。
说到这个事件，我发现，这个组件真的大量运用了事件，这让我体会到事件作为一种观察者模式，它的监听和触发真是太能为不同层之间的对象解耦，但就是阅读代码会很不顺畅。
这里面涉及到的细节太多了，知道这样做是为什么之后，更难的是要相通他为什么要这样做。所以阅读源码不容易呀。