消息中间件NMQ
1.What is nmq?
nmq = new message queue;
一个通用消息队列系统
为在线服务设计
什么是消息队列？问什么需要？有哪些功能？
消息队列的本质：1.多个不同的应用之间实现相互通信的一种异步传输模式2.异步3.解耦
业界有哪些比较好的mq？
yahoo YMB 、twitter Kestrel、amazon SQS、apache kafka
百度的nmq和bigpipe
那么为什么会有这么多的实现呢？
影响设计的关键需求：
1.数据安全性
2.传输实时性
3.时序需求
4.吞吐需求
5.消费方形态
6.消息关联形态
现在介绍一下百度的nmq(看一下nmq的设计考量)：
1.项目起源于大社区
2.重复开发、分散运维；极大的人力浪费；
并发+时序的难点，让rd头疼
核心+单点的运维，让op蛋疼
3.架构的发展，让老的系统不在适合
4.业务的发展，对性能、可扩展性有了更高的要求；
mq的本质需求：
1.数据安全性————》其实还好
2.传输实时性————》要求很高
3.吞吐需求————》很大
4.时序需求————》真的需要
5.消费方形态————》多样
6.消息关联形态————》1vN
nmq的其他需求：
1.集中运维
2.解耦
3.运维平台化、自动化
4.完善的功能，强大的时序+并发控制
5.支持国际化数据互通
模型设计(第一个问题)
nmq是基于消息的队列，还是基于消费者的队列
考虑点：
1.存储容量
2.运维便利度
3.扩展性
4.开发成本
所以最终选择应该基于消息本身。
模型设计(第二个问题)：
1.推或者拉
2.核心问题：谁维护信息？
为了更加深入的对“推”和“拉”这两种模式进行对比，可以将consumer分为2类：
1.竞争模式：一个consumer模块部署很多机器，但所有机器竞争消费同一份消息。
2.多主模式：一个consumer模块部署很多机器，每个机器都消费全量消息。
推模型的分析：
1.推模型是消息集中管理方式，消息队列知道consumer的一切。
2.可以支持2种consumer模式，容易实现各种策略。
3.优点是灵活，什么都可以做
4.缺点是耦合，消息队列本身的运维是问题
拉模式分析
1.对多主的consumer：完美
消息队列只负责消息的存储和查询
运维便利、架构清晰、简单
2.对竞争的consumer：难以支持
两种模式的选择
1.竞争模式会是我们今后的主流模式和大趋势；
数据逻辑层和存储引擎层的分离
数据的拆分和冗余，都会在存储引擎层实现
2.PHP模块实现“拉”有一定的难度
3.实现策略的灵活性和重要，推模式有天然的优势
4.拉模式，会带来更大的迁移代价
5.最终选择“推”模式
消息标识：
1.msg = product+topic+cmd
2.product产品线标识
3.topic
按业务划分的消息序列，逻辑上的概念，可小可大。
nmq只保证相同的topic内的命令时序
4.cmd消息类别的最终标识，不同topic之间可以同名
模型：
1.proxy
消息唯一入口，以topic为单位消息分流
2.topic-server(ts)
消息存储。级联和备份
3.pusher
消息发送，协议可扩展
nmq集群图片：
nmq的扩展性设计：
1.垂直扩展
当接收同一个topic的consumer增多，导致pusher出现性能瓶颈。
可以通过ts级联扩展多个pusher解决，支持多级级联
2.水平扩展
当一个topic的命令增多，导致超过单机ts性能极限
可以通过将该topic拆分到多个ts解决；比如按照某个partition key进行拆分；拆分后，只有相同pk的消息才能保证时序。
运维设计
1.队列的存储粒度
一个ts内部的所有topic串行存储于一个队列中，共享一维transid；
牺牲性能换取简单，易运维
2.主从同步和切换
ts级联和备份合一；slave主动从master拉数据，配合资源定位，简化主从切换步骤。
异步pipeline模式，强吞吐，支持跨机房。
并发+时序
1.一发一答的串行更新模式远不能满足更新性能的需求
2.在并发的前提下，可以做到按照某个key的时需保证；
具有相同key的消息，可以保证时序
比如接贴吧发帖的命令的consumer，可以通过配置做到不同发帖更新并发，但保证同一个吧的发帖是有序串行的；
3.实现
正在发送窗口+待发送窗口
发送先前check是否有互斥的消息正在发送
国内跨城市方案：
国际化数据互通方案：
