Topic 话题模式
q1和q2不动，消费者该干什么干什么，关键是生产者发过来的数据该怎么走，把工作模式换成topic，就把原来等值匹配routing_key，变成了模式匹配。
原来等值匹配，现在模式匹配，成了高级路由了，仅此而已，是一种高级的支持模式匹配的路由模式，叫topic
如果是多个组成，中间应该使用.点号分割的单词组成，最长255个字节
*支持通配符，就两个 ，星号代表严格的一个单词，#代表0或多个单词
如果queue绑定的routing_key只有一个#，就代表什么都可以匹配
使用topic的时候，大部分都需要约定消息该如何去走
在之前t5的基础上再做扩展，t7,t8，products生产的东西，有不同颜色colors，话题有两个phone.,.black，产品和颜色会形成交叉
前面这部分不变
绑定的时候需要改变，改成topic
现在用绑定的方式解决了一些问题
消费者代码中，routing_key就要用topic，因为没有其他的在用，在queue前面需要一个匹配的东西就是routing_key，把topic放到这里来
消息的生产者需要做些事情，模拟随机生成消息，现在的routing_key，有可能是tv.green,phone.black等，随机拼个字符串，只不过中间加个.点号间隔
把消息改一下看的更清楚
消费过程改怎么样怎么样，建立queue就建立，该和交换机绑定就绑定，只不过在绑定的时候routing_key就变成模式的了
现在有两个消费者，一个管第一个话题，黑色，一个管只管phone
生产10条消息，消费者这段有几条消息，有可能出现phone.black，这条消息只要符合就发给两个，这就是一对多了
消费者执行一下
交换机就多了products
**一个绑定phone.，一个绑定.black **
生产一下数据
产生了一个正好是phone.black，1变2了
现在多生产几条数据
现在black就重复了，非black就不重复了，black和phone可以看到。tv.green这种就丢掉了
topice就是带匹配模式的高级路由
两边都可以建立交换机和queue，虚拟主机不能在这里建，虚拟主机应该由管理员先建好，一般queue动态创建更多一点，一般宁愿让消费者等着，也不让生产者等着，消费者在queue上等待数据，有一些消费来不及，就再增加消费者
一般来讲routing模式用的多点，是否需要用到topic的模式匹配按需决定。可以观察到交换机是在路由消息的时候，只要和queue的routing_key匹配，就把消息发给该queue，如果还有一个routing_key匹配，就再发一份，产生一对多
交换机完成数据的路由，但是路由给谁，就需要queue绑定的时候告诉它跟哪个交换机绑定，关心的是什么样的routing_key，然后交换机就可以根据routing_key，将数据投递到不同的queue中，queue在使用过程中，如果绑定一个就拿一个一个，绑定多个就是轮循方式，数据只能被拿走一次，拿走就没了，下一个只能拿另一个数据了，如果需要一边多就需要用路由模式或者广播模式来解决问题。
大多数使用路由方式，只不过路由方式结合工作队列来用
RPC用的很少，用很多第三方很好的rpc，比如阿里的double
消息队列作用
消息队列作用，主要亮点：
1.解耦（原来代码都是耦合一起，里面用多线程用一个queue，这样不易扩展，现在把queue分开，我们代码就可以分开，各个功能就可以单独写成应用程序，功能程序越少，越稳定，所谓的微服务就是将以前的大程序拆成小程序了。服务端和客户端是遵照自己的协议通信，但是服务和服务通信就是需要通过RPC来了，中间因为速度原因，都需要异步调用，可以用第三方队列也可以用http异步调用，这些方案都是可以用的）
2.生产者和消费者速度匹配问题，要么异步调用比如ajax，等它回来用回调方式，或者用消息队列，稍微上规模的项目，都需要分层，分模块开发，模块间和系统间最好不要直接调用，往往需要一个中间层，有公共开放接口，供这些模块和系统进行调用，系统间把他们分离开。
调用有可能造成并发的问题，生产的数据由第三方消息队列来承担高并发压力，这样使你的程序简单了。单体程序抗压有限，所有高并发解决方案都是一个搞不定，就来2个，3个
消息队列只要支持amqp协议，用pika来开发都一样，现在开发的都是amqp协议支持的，大多数消息队列都支持amqp协议
rabbitmq是消息中间件中的一种，还有activemq，rocketmq，现在还有很多公司用rabbitmq，erlang语言很高效，只不过语言社区生态不好，用的人比较少，我们部署只需要把erlang依赖安装好，根据自己需要选择模式
