13 | 架构设计流程：详细方案设计

可以完善的细节： 1、发送端和消费端如何寻址 利用zookeeper做注册中心，把broker的地址注册到zk上，发送端和消费端只要配置注册中心的地址即可获取集群所以broker地址，当有broker下线时，发送端和消费端能及时更新broker地址。 2、发送端消息重试 当发送消息发生网络异常时（不包括超时异常），可以重新选择下一台broker来重试发送，重试策略可以自定义。 3、消息消费采用pull还是push？ 考虑push模式会更复杂，故放弃，采用pull模式，消费端主动去拉，为了达到与push模式相同的低延迟效果，可以采用长轮询的方式，消费端轮询拉取消息费，当有消费可消费时，返回消息，如果没有可消费的消息，挂起当前线程，直到超时或者有可消费的消息为止。 4、消息重复问题 消息中间件不解决消息重复的问题，有业务系统自己根据业务的唯一id去重。 5、顺序消息 发送端在发生顺序消息时，只发送到相同broker的相同队列，消费端消费时，顺序消息只能由同一个消费端消息。 6、定时消息 发送端指定消息延时多长时间消费，broker端定时扫描定时消息，达到延时时间的消息加入到消费队列。 7、事务消息 发送端分两步，先预发送消息，broker端只记录消息为预发送状态，再执行本地事务，然后再根据本地事务的成功或者失败发送确认消息（回滚还是提交），这步如果发生异常，broker启动定时任务，把未确认的消息发送给发送端回查事务状态（需要发送端提供回查接口）。 目前就想到这么多。

很有幸我们现在的架构师就是PPT架构师，我觉得他的优点就是懂了很多的概念，能说话到，可以忽悠住老板。缺点也很明显，就是他知道的都不是很深，比如曾经我们的搜索引擎原型，他并不能说出ES和solr的优缺点(当然我也不知道，平时用solr多点)，最后我们选了ES，他给的原因就是朋友说的ES比solr好，后面搜索这里就交给我来搞了。我们是互联网项目，在重构的项目的时候他选择了jpa，这就导致变化需求的时候，查询这块比较麻烦，不灵活。 其实就像前面说的，每个技术存在就是合理的，只是每个有每个技术的使用点，架构师应该对常见的技术栈原理非常清楚，知道什么时候应该使用什么技术。 我理解的PPT架构师的特点就是知识点多，知道概念，能虎住老板，缺点就是技术栈不咋滴，特别是细节上。我觉得架构师应该帮助员工成长，而不是遇到问题就说这个问题我没遇到过，你上网搜索下解决方案。 初次留言，欢迎板砖

就一些新的技术引入，架构师需要做哪些技术验证，或者研究到什么深度以后，才认为该技术适合呢？

PPT架构师以脱离一线时间较久的领导居多吧。很多技术他们没有真正使用过，只是从各种途径得知很强大，其他公司（BAT）都在用，于是就在PPT中写入这种技术。缺点就是很容易做出貌似可行，深究其细节全是坑的设计。

认识一个工作10多年的架构师，天天只会说代码命名和注释的问题，从来没谈过什么高大上的架构，也从来没见他写过代码，有一次我来他来帮我看一个问题，他装没听见，走了……

好吧，我就是ppt架构师😓 架构的层级看，有企业架构、业务架构、IT架构等，EA分业务、应用、技术、数据、基础设施等，不同的架构对架构师要求不一样，这个教程主要是讲技术架构，要求架构师对技术细节掌握较深，其他几种架构师虽然在写ppt但是真得不简单呢，知识面广度，行业理解，客户需求，抽象思维，心理揣摩，产品知识样样都要掌握

真见过PPT架构师，1.自己基本不写代码，2.对某一项技术比较精通所以架构设计时尽量往这上面靠，比如对mysql很熟悉所以设计出的系统大量用到mysql 存储过程，3.设计出来的架构完全不考虑老系统兼容或者迁移难度

没理解日志表在这里的意义，如果单纯是为了尾部追加，消息表也是尾部追加的操作吧，如果是为了记录消息，可消息表本身也记录了消息。 原因我能想到的作用，是记录消息存储队列，即哪个消息存在了哪个队列 另外，消息表中是不是应该添加一个消息消费确认字段，当消息被消费成功后，更改该字段，这也可以避免重复消费 以上，请华哥指点

业务系统发布消息时，首先写入到日志表，日志表写入成功就代表消息写入成功；后台线程再从日志表中读取消息写入记录，将消息内容写入到消息表中。 业务系统读取消息时，从消息表中读取。 这里的设计是不是冗余了？？

华哥，"日志表是尾部追加，性能高"，这个具体实施细节能否讲解下。