2018-05-28可以完善的细节：
1、发送端和消费端如何寻址
利用zookeeper做注册中心，把broker的地址注册到zk上，发送端和消费端只要配置注册中心的地址即可获取集群所以broker地址，当有broker下线时，发送端和消费端能及时更新broker地址。
2、发送端消息重试
当发送消息发生网络异常时（不包括超时异常），可以重新选择下一台broker来重试发送，重试策略可以自定义。
3、消息消费采用pull还是push？
考虑push模式会更复杂，故放弃，采用pull模式，消费端主动去拉，为了达到与push模式相同的低延迟效果，可以采用长轮询的方式，消费端轮询拉取消息费，当有消费可消费时，返回消息，如果没有可消费的消息，挂起当前线程，直到超时或者有可消费的消息为止。
4、消息重复问题
消息中间件不解决消息重复的问题，有业务系统自己根据业务的唯一id去重。
5、顺序消息
发送端在发生顺序消息时，只发送到相同broker的相同队列，消费端消费时，顺序消息只能由同一个消费端消息。
6、定时消息
发送端指定消息延时多长时间消费，broker端定时扫描定时消息，达到延时时间的消息加入到消费队列。
7、事务消息
发送端分两步，先预发送消息，broker端只记录消息为预发送状态，再执行本地事务，然后再根据本地事务的成功或者失败发送确认消息（回滚还是提交），这步如果发生异常，broker启动定时任务，把未确认的消息发送给发送端回查事务状态（需要发送端提供回查接口）。
目前就想到这么多。展开作者回复: 厉害，基本上重点都涵盖了
115
2018-05-26PPT架构师以脱离一线时间较久的领导居多吧。很多技术他们没有真正使用过，只是从各种途径得知很强大，其他公司（BAT）都在用，于是就在PPT中写入这种技术。缺点就是很容易做出貌似可行，深究其细节全是坑的设计。作者回复: BAT三个字是设计捷径，但也很多坑
1 23
2018-05-26很有幸我们现在的架构师就是PPT架构师，我觉得他的优点就是懂了很多的概念，能说话到，可以忽悠住老板。缺点也很明显，就是他知道的都不是很深，比如曾经我们的搜索引擎原型，他并不能说出ES和solr的优缺点(当然我也不知道，平时用solr多点)，最后我们选了ES，他给的原因就是朋友说的ES比solr好，后面搜索这里就交给我来搞了。我们是互联网项目，在重构的项目的时候他选择了jpa，这就导致变化需求的时候，查询这块比较麻烦，不灵活。
其实就像前面说的，每个技术存在就是合理的，只是每个有每个技术的使用点，架构师应该对常见的技术栈原理非常清楚，知道什么时候应该使用什么技术。
我理解的PPT架构师的特点就是知识点多，知道概念，能虎住老板，缺点就是技术栈不咋滴，特别是细节上。我觉得架构师应该帮助员工成长，而不是遇到问题就说这个问题我没遇到过，你上网搜索下解决方案。
初次留言，欢迎板砖展开作者回复: 架构师确实需要技术面宽，但别只知道技术名词，基本使用，关键原理，优缺点都需要了解
20
2018-05-31认识一个工作10多年的架构师，天天只会说代码命名和注释的问题，从来没谈过什么高大上的架构，也从来没见他写过代码，有一次我来他来帮我看一个问题，他装没听见，走了……作者回复: 你们公司还要架构师么😂😂
17
2018-06-04华哥，这个专栏讲解架构设计的概念、设计原则、设计规则等主演偏重理论上的设计。对很多没有亲身经历过架构设计的程序猿又想踏入架构师之旅，文章阅读之后文中讲的理论基本也都能懂，但要自己真正落地恐怕非常难？要是这个专栏之后华哥能再写一个专栏，就针对“前浪微博”的消息队列从设计前期、详细设计、框架搭建、开发实现、最后测试部署的一套流程的专栏。让我们亲自动手感受从系统设计到最终系统上线的一套完整流程。相信会受很多人欢迎及订阅。 16
2018-05-26就一些新的技术引入，架构师需要做哪些技术验证，或者研究到什么深度以后，才认为该技术适合呢？作者回复: 基本原理，优点缺点，关键设计点，架构师至少要安装过，编写demo体验过，确定选型后，要进行性能和可用性测试例如es的索性设计就是关键设计点
15
2018-05-30我们的架构师连PPT都懒得做。 7
2018-05-26真见过PPT架构师，1.自己基本不写代码，2.对某一项技术比较精通所以架构设计时尽量往这上面靠，比如对mysql很熟悉所以设计出的系统大量用到mysql 存储过程，3.设计出来的架构完全不考虑老系统兼容或者迁移难度作者回复: 架构师手里有一把锤子，然后所有的问题都是钉子😂
7
2018-11-28好吧，我就是ppt架构师😓
架构的层级看，有企业架构、业务架构、IT架构等，EA分业务、应用、技术、数据、基础设施等，不同的架构对架构师要求不一样，这个教程主要是讲技术架构，要求架构师对技术细节掌握较深，其他几种架构师虽然在写ppt但是真得不简单呢，知识面广度，行业理解，客户需求，抽象思维，心理揣摩，产品知识样样都要掌握作者回复: 你这种叫“系统分析师”或者“解决方案架构师”更贴切😄
1 6
2018-05-26业务系统发布消息时，首先写入到日志表，日志表写入成功就代表消息写入成功；后台线程再从日志表中读取消息写入记录，将消息内容写入到消息表中。
业务系统读取消息时，从消息表中读取。
这里的设计是不是冗余了？？展开作者回复: 日志表是尾部追加，性能高
5
2018-05-28请教华仔：您说的”日志表是尾部追加，性能高”，这个日志表是用myisam存储引擎吗？我刚刚查了文档innodb只有系统表空间和日志文件是序列化写呀，普通表文件都是随机写。 请指教。作者回复: 这个日志表是我们自己设计的，不管是innodb还是myisam都可以，我说的尾部追加是指我们只会往日志表插入数据，类似kafka的文件尾部追加一样
4
2018-05-26对于PPT架构师，总结有以下几个特点：
1）整体思路照搬
2）不能准确定位业务需要解决的痛点
3）对所需技术的原理理解不深
4）执行到后期，返工及补坑的工作比较多
.......展开作者回复: PPT可以造火箭，实际实现只能造鞭炮
4
2018-05-29华哥，"日志表是尾部追加，性能高"，这个具体实施细节能否讲解下。作者回复: 其实高性能的很多存储方案都是这样设计的，MySQL有Binlog，HBase有HLog，道理都是相通的。
在这个备选方案中，我们设计一个日志表，假设名称叫MQ_LOG，包含ID, time, queueName, message, publisher等几个字段，每次收到消息发布请求时先写这个表，每次都是表尾部追加。
如果不用自己设计的日志表，mysql的binlog也类似尾部追加，性能也不错，缺点就是没法自己灵活实现各种刷盘机制了。 3
2018-05-28我也没有明白作者说的日志表尾部追加性能好，具体是什么操作，还望赐教，多谢了！ 3
2018-05-26我理解的ppt架构师和大家不同，我理解的ppt架构师往往类似咨询公司的那种，要充分熟悉领域业务，有成熟方案经验，只要方案成功过就行，至于怎么落地就是你的事了。这种会有市场，主要还是对某些领域的整体摸得比较熟。
今天这个方案，有一个日志消息表的目的，是为了把消费和写入操作带来的压力分开嘛？考虑到写和读的比例是11比10，所以日志表每个库只有一个？
文章似乎没提具体如何记录消费者读取消息位置，这也是个关键trade off的点，决定了qos。下期会说？
另外有个吹毛求疵的想法，自研发sdk往往比看起来的难，需要设计功力，有bug了如何及时分发新版本都是问题。选型时需要开发sdk的都是减分项。
怎么看这都是消息队列擅长的场景，使用成熟三方实现成本会非常非常低，不能和运维大哥商量一下么？-_-展开作者回复: 1. 你说的一般叫系统分析师
2. 日志表是尾部追加，写入性能高，日志表一个库只有一个
3. sdk写稳定确实需要一段时间
4. 运维大哥不怕每天维护，最怕出问题几个小时甚至几天都搞不定 3
2018-12-25PPT架构师，基本上是从网上找资料过来，没有根据业务中实际情况来进行验证，而确定了方案。是这样子吗？作者回复: 是的
2
2018-09-06请问备选设计方案和详细设计方案之间大概有多大的差别，是否有可参考案例作者回复: 第50篇的文档模板给了一个样例参考
2
2018-07-31ppt架构师就是挖好坑让小弟们跳，跳进去出不来了也没人救你，怪你能力有问题，太坑作者回复: 架构师这么爽呀😄
2
2018-07-29有个问题咨询下，选用ip_hash作负载均衡策略时，如果一台机器挂掉了，因为有对应ip机器上存储session的原因，如何保证整体的映射规则的平稳过渡呢作者回复: 如果保存在内存中，机器宕机就没法保证了，如果要保证，可以用缓存存储session
2
2018-05-28看来ppt架构师还是很多的啊，应该推荐他们来看看老师的文章o(^o^)o 2