谈起音讯队列，心田还是会有些波澜。

音讯队列，缓存，分库分表是高并发解决方案三剑客，而音讯队列是我最喜爱，也是思考最多的技术。

我想依照上面的四个阶段分享我与音讯队列的故事，同时也是对我技术成长经验的回顾。

• 初识：ActiveMQ
• 进阶：Redis&RabbitMQ
• 升华：MetaQ
• 钟情：RocketMQ

1 初识 ActiveMQ

1.1 异步 & 解耦

2011 年初，我在一家互联网彩票公司做研发。

我负责的是用户核心零碎，提供用户注册，查问，批改等根底性能。用户注册胜利之后，须要给用户发送短信。

因为原来都是面向过程编程，我就把新增用户模块和发送短信模块都揉在一起了。

起初都还好，但问题缓缓的显现出来。

• 短信渠道不够稳固，发送短信会达到 5 秒左右，这样用户注册接口耗时很大，影响前端用户体验;
• 短信渠道接口发生变化，用户核心代码就必须批改了。但用户核心是外围零碎。每次上线都必要谨小慎微。这种感觉很顺当，非核心性能影响到外围零碎了。

第一个问题，我能够采取线程池的办法来做，次要是 异步化。但第二个问题却让我束手无措。

于是我向技术经理求教，他通知我引入音讯队列去解决这个问题。

• 将发送短信性能独自拆成独立的 Job 服务;
• 用户核心用户注册胜利后，发送一条音讯到音讯队列，Job 服务收到音讯调用短信服务发送短信即可。

这时，我才明确: 音讯队列最外围的性能就是 <font color=”red”>异步 </font> 和 <font color=”red”> 解耦</font>。

1.2 调度核心

彩票零碎的业务是比较复杂的。在彩票订单的生命周期里，通过创立，拆分子订单，出票，算奖等诸多环节。
每一个环节都须要不同的服务解决，每个零碎都有本人独立的表，业务性能也绝对独立。如果每个利用都去批改订单主表的信息，那就会相当凌乱了。

公司的架构师设计了 <font color=”red”>调度核心</font> 的服务，调度核心的职责是保护订单外围状态机，订单返奖流程，彩票外围数据生成。

调度核心通过 音讯队列 和出票网关，算奖服务等零碎传递和替换信息。

这种设计在那个时候青涩的我的眼里，几乎就是水滴 vs 人类舰队，降维打击。

随着我对业务了解的不断深入，我隐约感觉：“好的架构是简洁的，也是应该易于保护的”。

当彩票业务日均千万交易额的时候，调度核心的研发保护人员也只有两个人。调度核心的源码里业务逻辑，日志，代码标准都是极好的。

在我日后的程序人生里，我也会下意识模拟调度核心的编码方式，“不玩奇技淫巧，代码是给人浏览的”。

1.3 重启大法

随着彩票业务的爆炸增长，每天的音讯量从 30 万激增到 150~200 万左右，所有看起来仿佛很安稳。

某一天双色球投注截止，调度核心无奈从音讯队列中生产数据。音讯总线处于只能发，不能收的状态下。整个技术团队都处于极度的焦虑状态，“要是出不了票，那可是几百万的损失呀，要是用户中了两个双色球？那可是千万呀”。大家急得像热锅上的蚂蚁。

这也是整个技术团队第一次遇到生产沉积的状况，大家都没有教训。

首先想到的是多部署几台调度核心服务，部署实现之后，调度核心生产了几千条音讯后还是 Hang 住了。这时，架构师只能采纳 重启 的策略。你没有看错，就是重启大法。说起来真的很羞愧，但过后真的只能采纳这种形式。

调度核心重启后，生产了一两万后又 Hang 住了。只能又重启一次。来来回回继续 20 屡次，像挤牙膏一样。而且随着出票截止工夫的邻近，这种思维上的缓和和恐惧感更加强烈。终于，通过 1 小时的手工一直重启，音讯终于生产完了。

我过后正好在读毕玄老师的《分布式 java 利用根底与实际》，猜测是不是线程阻塞了，于是我用 Jstack 命令查看堆栈状况。果然不出所料，线程都阻塞在提交数据的办法上。

咱们马上和 DBA 沟通，发现 oracle 数据库执行了十分多的大事务，每次大的事务执行都须要 30 分钟以上，导致调度核心的调度出票线程阻塞了。

技术部起初采取了如下的计划躲避沉积问题：

1. 生产者发送音讯的时候，将超大的音讯拆分成多批次的音讯，缩小调度核心执行大事务的几率;
2. 数据源配置参数，如果事务执行超过肯定时长，主动抛异样，回滚。

1.4 复盘

Spring 封装的 ActiveMQ 的 API 十分简洁易用，应用过程中真的十分难受。

受限于过后彩票技术团队的技术水平和视线，咱们在应用 ActiveMQ 中遇到了一些问题。

1. 高吞吐下，沉积到肯定音讯量易 Hang 住；

技术团队发现在吞吐量特地高的场景下，如果音讯沉积越大，ActiveMQ 有较小几率会 Hang 住的。

出票网关的音讯量特地大，有的音讯并不需要马上生产，然而为了躲避音讯队列 Hang 住的问题，出票网关生产数据的时候，先将音讯先长久化到本地磁盘，生成本地 XML 文件，而后异步定时执行音讯。通过这种形式，咱们大幅度晋升了出票网关的生产速度，根本杜绝了出票网关队列的沉积。

但这种形式感觉也挺怪的，生产音讯的时候，还要本地再存储一份数据，音讯存储在本地，如果磁盘坏了，也有丢音讯的危险。

2. 高可用机制待欠缺

咱们采纳的 master/slave 部署模式，一主一从，服务器配置是 4 核 8G。

这种部署形式能够同时运行两个 ActiveMQ，只容许一个 slave 连贯到 Master 下面，也就是说只能有 2 台 MQ 做集群，这两个服务之间有一个数据备份通道，利用这个通道 Master 向 Slave 单向地数据备份。这个计划在理论生产线上不不便，因为当 Master 挂了之后，Slave 并不能主动地接管 Client 发来的请来，须要手动干涉，且要进行 Slave 再重启 Master 能力复原负载集群。

还有一些很诡异丢音讯的事件，生产者发送音讯胜利，但 master 控制台查问不到，但 slave 控制台居然能查问到该音讯。

但消费者没有方法生产 slave 上的音讯，还得通过人工染指的形式去解决。

2 进阶 Redis&RabbitMQ

2014 年，我在艺龙网从事红包零碎和优惠券系统优化相干工作。

2.1 Redis 能够做音讯队列吗

酒店优惠券计算服务应用的是初代流式计算框架Storm。Storm 这里就不具体介绍，能够参看上面的逻辑图：

这里咱们的 Storm 集群的水源头（数据源）是 redis 集群，应用 list 数据结构实现了音讯队列的 push/pop 性能。

流式计算的整体流程：

1. 酒店信息服务发送酒店信息到 Redis 集群 A /B;
2. Storm 的 spout 组件从 Redis 集群 A / B 获取数据, 获取胜利后，发送 tuple 音讯给 Bolt 组件;
3. Bolt 组件收到音讯后，通过经营配置的规定对数据进行荡涤;
4. 最初 Storm 把解决好的数据发送到 Redis 集群 C;
5. 入库服务从 Redis 集群 C 获取数据, 存储数据到数据库;
6. 搜寻团队扫描数据库表，生成索引。

这套流式计算服务每天解决千万条数据，解决得还算顺利。
但计划在团队外部还是有不同声音:

• storm 的拓扑降级时候，或者优惠券服务重启的时候，偶然呈现丢音讯的状况。但音讯的失落，对业务来讲没有那么敏感，而且咱们也提供了手工刷新的性能，也在业务的容忍范畴内;
• 团队须要常常关注 Redis 的缓存使用量，放心 Redis 队列沉积, 导致 out of memory;
• 架构师认为搜寻团队间接扫描数据库不够解耦，倡议将 Redis 集群 C 替换成 Kafka，搜寻团队从 kafka 间接生产音讯，生成索引;

我认为应用 Redis 做音讯队列应该满足如下条件：

1. 容忍小概率音讯失落，通过定时工作 / 手工触发达到最终统一的业务场景;
2. 音讯沉积概率低，有相干的报警监控;
3. 消费者的生产模型要足够简略。

2.2 RabbitMQ 是管子不是池子

RabbitMQ 是用 erlang 语言编写的。RabbitMQ 满足了我的两点需要：

1. 高可用机制。艺龙外部是应用的镜像高可用模式，而且这种模式在艺龙曾经应用了较长时间了，稳定性也失去了肯定的验证。
2. 我负责的红包零碎里，RabbitMQ 每天的吞吐也在百万条音讯左右，音讯的发送和生产都还挺完满。

优惠券服务原应用SqlServer，因为数据量太大，技术团队决定应用分库分表的策略，应用公司自主研发的分布式数据库 DDA。

因为是第一次应用分布式数据库，为了测试 DDA 的稳定性，咱们模仿发送 1000 万条音讯到 RabbitMQ，而后优惠券重构服务生产音讯后，依照用户编号 hash 到不同的 mysql 库。

RabbitMQ 集群模式是镜像高可用，3 台服务器，每台配置是 4 核 8G。

咱们以每小时 300 万条音讯的速度发送音讯，最开始 1 个小时生产者和消费者体现都很好，但因为消费者的速度跟不上生产者的速度，导致音讯队列有积压状况产生。第三个小时，音讯队列已沉积了 500 多万条音讯了，生产者发送音讯的速度由最开始的 2 毫秒激增到 500 毫秒左右。RabbitMQ 的控制台已血溅当场，标红报警。

这是一次无心中的测试，从测试的状况来看，RabbitMQ 很优良，但 <font color=”red”>RabbitMQ 对音讯沉积的反对并不好，当大量音讯积压的时候，会导致 RabbitMQ 的性能急剧下降</font>。

有的敌人对我讲：“RabbitMQ 明明是管子，你非得把他当池子？”

随着整个互联网数据量的激增, 很多业务场景下是容许适当沉积的，只有保障消费者能够安稳生产，整个业务没有大的稳定即可。

我心外面越来越置信：音讯队列既能够做 管子 ，也能够当做 池子。

3 升华 MetaQ

Metamorphosis 的起源是我从对 linkedin 的开源 MQ–当初转移到 apache 的 kafka 的学习开始的，这是一个设计很独特的 MQ 零碎，它采纳 pull 机制，而 不是个别 MQ 的 push 模型，它大量利用了 zookeeper 做服务发现和 offset 存储，它的设计理念我十分观赏并同意，强烈建议你浏览一下它的设计文档，总体上说 metamorphosis 的设计跟它是完全一致的。— MetaQ 的作者庄晓丹

3.1 惊艳消费者模型

2015 年，我次要从事神州专车订单研发工作。

MetaQ 满足了我对于音讯队列的空想：“<font color=”red”> 分布式，高吞吐，高沉积 </font>”。

MetaQ 反对两种生产模型：集群生产 和播送生产，因为以前应用过的消费者模型都是用队列模型，当我第一次接触到这种公布订阅模型的时候还是被惊艳到了。

▍ 集群生产

订单创立胜利后，发送一条音讯给 MetaQ。这条音讯能够被派单服务生产，也能够被 BI 服务生产。

▍ 播送生产

派单服务在讲订单指派给司机的时候，会给司机发送一个推送音讯。推送就是用播送生产的模式实现的。

大体流程是:

1. 司机端推送服务是一个 TCP 服务，启动后，采纳的是播送模式生产 MetaQ 的 PushTopic;
2. 司机端会定时发送 TCP 申请到推送服务，鉴权胜利后，推送服务会保留司机编号和 channel 的援用；
3. 派单服务发送推送音讯到 MetaQ；
4. 推送服务的每一台机器都会收到该音讯，而后判断内存中是否存在该司机的 channel 援用，若存在，则推送音讯。

这是十分经典的播送生产的案例。我已经研读京麦 TCP 网关的设计，它的推送也是采纳相似的形式。

3.2 激进的消峰

2015 年是打车大战硝烟弥漫的一年。

对神州专车来讲，随着订单量的一直增长，欣慰的同时，性能的压力一劳永逸。早晚高峰期，用户打车的时候，常常点击下单常常无响应。
在零碎层面来看，专车 api 网关发现大规模超时，订单服务的性能急剧下降。数据库层面压力更大，高峰期一条记录插入居然须要 8 秒的工夫。

整个技术团队须要尽快晋升专车零碎的性能，此前曾经依照模块畛域做了数据库的拆分。但零碎的瓶颈仍然很显著。

咱们设计了当初看来有点激进的计划：

1. 设计订单缓存。缓存计划大家要有趣味，咱们能够当前再聊，外面有很多能够详聊的点;
2. 在订单的载客生命周期里，订单的批改操作先批改缓存，而后发送音讯到 MetaQ，订单落盘服务生产音讯，并判断订单信息是否失常（比方有无乱序)，若订单数据无误，则存储到数据库中。

这里有两个细节：

1. 消费者生产的时候须要程序生产，实现的形式是依照 <font color=”purple”> 订单号 </font> 路由到不同的 partition，同一个订单号的音讯，每次都发到同一个 partition;
   
2. 一个守护工作，定时轮询以后正在进行的订单，当缓存与数据不统一时候，修复数据，并发送报警。

这次优化大大晋升订单服务的整体性能，也为起初订单服务库分库分表以及异构打下了松软的根底，依据咱们的统计数据，根本没有产生过缓存和数据库最初不统一的场景。但这种计划对缓存高可用有较高的要求，还是有点小激进吧。

3.3 音讯 SDK 封装

做过基础架构的同学可能都有教训：“三方组件会封装一层”，神州架构团队也是将 metaq-client 封装了一层。

在我的思维外面，封装一层能够缩小研发人员应用第三方组件的心智投入，对立技术栈，也就如此了。

直到产生一次意外，我的思维降级了。那是一天下午，整个专车服务解体较长时间。技术团队发现：” 专车应用 zookeeper 做服务发现。zk 集群的 leader 机器挂掉了，始终在选主。”

长期解决后，咱们发现 MetaQ 和服务发现都应用同一套 zk 集群，而且 consumer 的 offset 提交，以及负载平衡都会对 zk 集群进行大量的写操作。

为了缩小 MetaQ 对 zk 集群的影响，咱们的指标是：“MetaQ 应用独立的 zk 集群”。

1. 须要部署新的 zk 集群；
2. MetaQ 的 zk 数据须要同步到新的集群；
3. 保障切换到新的集群，应用服务根本无感知。

我很好奇向架构部同学求教，他说新的集群曾经部署好了，但须要同步 zk 数据到新的集群。他在客户端里增加了 双写 的操作。也就是说：咱们除了会写原有的 zk 集群一份数据，同时也会在新的 zk 集群写一份。
过了几周后，MetaQ 应用独立的 zk 集群这个工作曾经实现了。

<font color=”red”> 这一次的经验带给我很大的感叹：“还能够这么玩？”</font>，也让我思考着：三方组件封装没有想像中那么简略。

咱们能够看下 快手 音讯的 SDK 封装策略：

1. 对外只提供最根本的 API，所有拜访必须通过 SDK 提供的接口。简洁的 API 就像冰山的一个角，除了对外的简略接口，上面所有的货色都能够降级更换，而不会毁坏兼容性 ;
2. 业务开发起来也很简略，只有须要提供 Topic（全局惟一）和 Group 就能够生产和生产，不必提供环境、NameServer 地址等。SDK 外部会依据 Topic 解析出集群 NameServer 的地址，而后连贯相应的集群。生产环境和测试环境环境会解析出不同的地址，从而实现了隔离；
3. 上图分为 3 层，第二层是通用的，第三层才对应具体的 MQ 实现，因而，实践上能够更换为其它消息中间件，而客户端程序不须要批改；
4. SDK 外部集成了热变更机制，能够在不重启 Client 的状况下做动静配置，比方下发路由策略（更换集群 NameServer 的地址，或者连贯到别的集群去），Client 的线程数、超时工夫等。通过 Maven 强制更新机制，能够保障业务应用的 SDK 基本上是最新的。

3.4 重构 MetaQ , 自成体系

我有一个习惯 : “ 常常找运维，DBA，架构师理解以后零碎是否有什么问题，以及他们解决问题的思路。这样，我就有另外一个视角来扫视公司的零碎运行状况 ”。

MetaQ 也有他的毛病。

1. MetaQ 的基层通信框架是 gecko，MetaQ 偶然会呈现 rpc 无响应，利用假死的状况，不太好定位问题；
2. MetaQ 的运维能力单薄，只有简略的 Dashboard 界面，无奈实现自动化主题申请，音讯追踪等性能。

有一天，我发现测试环境的一台消费者服务器启动后，一直报链接异样的问题，而且 cpu 占用很高。我用 netstat 命令马上查一下，发现曾经创立了几百个链接。出于好奇心，我关上了源码，发现网络通讯框架 gecko 曾经被替换成了 netty。咱们马上和架构部的同学分割。

我这才明确：他们曾经开始重构 MetaQ 了。我素来没有想过重构一个开源软件，因为间隔我太远了。或者那个时候，我感觉本人的能力还达不到。

起初，神州自研的音讯队列自成体系了，曾经在生产环境运行的挺好。

时至明天，我还是很观赏神州架构团队。他们自研了音讯队列，DataLink（数据异构中间件），分库分表中间件等。他们违心去翻新，有勇气去做一个更好的技术产品。

我从他们身上学到很多。

兴许在看到他们重构 MetaQ 的那一刻，我的心里埋下了种子。

4 钟情 RocketMQ

4.1 开源的盛宴

2014 年，我收罗了很多的淘宝的音讯队列的材料，我晓得 MetaQ 的版本曾经降级 MetaQ 3.0，只是开源版本还没有放进去。

大概秋天的样子，我退出了 RocketMQ 技术群。誓嘉 (RocketMQ 创始人) 在群里说：“最近要开源了，放进去后，大家连忙 fork 呀”。他的这句话发在群里之后，群里都炸开了锅。我更是欢喜雀跃，期待着能早日见到阿里本人外部的消息中间件。

终于，RocketMQ 终于开源了。我急不可待想一窥他的风采。

因为我想学网络编程，而 RocketMQ 的通信模块 remoting 底层也是 Netty 写的。所以，RocketMQ 的通信层是我学习切入的点。

我模拟 RocketMQ 的 remoting 写了一个玩具的 rpc，这更大大提高我的自信心。正好，艺龙举办技术创新流动。我想想，要不尝试一下用 Netty 改写下 Cobar 的通信模块。于是参考 Cobar 的源码花了两周写了个 netty 版的 proxy，其实十分毛糙，很多性能不欠缺。起初，这次流动颁给我一个鼓励奖，当初想想都很好玩。

因为在神州优车应用 MetaQ 的关系，我学习 RocketMQ 也比拟得心应手。为了真正去了解源码，我时常会参考 RocketMQ 的源码，写一些轮子来验证我的学习效果。

尽管本人做了一些练习，但始终没有在业务环境应用过。2018 年是我真正应用 RocketMQ 的一年，也是有所得的一年。

▍ 短信服务

短信服务利用很宽泛，比方用户注册登录验证码，营销短信，下单胜利短信告诉等等。
最开始设计短信服务的时候，我想学习业界是怎么做的。于是把指标锁定在腾讯云的短信服务上。
腾讯云的短信服务有如下特点：

• 对立的 SDK，后端入口是 http/https 服务 , 调配 appId/appSecret 鉴权；
• 简洁的 API 设计：单发，群发，营销单发，营销群发，模板单发，模板群发。

于是，我参考了这种设计思路。

1. 模拟腾讯云的 SDK 设计，提供简略易用的短信接口；
2. 设计短信服务 API 端，接管发短信申请，发送短信信息到音讯队列；
3. worker 服务生产音讯，依照负载平衡的算法，调用不同渠道商的短信接口；
4. Dashboard 能够查看短信发送记录，配置渠道商信息。
   

短信服务是我真正意义第一次生产环境应用 RocketMQ，当短信一条条收回来的时候，还是蛮有成就感的。

▍ MQ 控制台

应用过 RocketMQ 的敌人，必定对上图的控制台很相熟。过后团队有多个 RocketMQ 集群，每组集群都须要独自部署一套控制台。于是我想着：能不能略微把控制台革新一番，能满足反对多组集群。

于是，撸起袖子干了起来。大略花了 20 天的工夫，咱们基于开源的版本革新了能反对多组集群的版本。做完之后，尽管能满足我最后的想法，然而做的很毛糙。而且搜狐开源了他们本人的 MQCloud，我看了他们的设计之后，感觉离一个音讯治理平台还很远。

起初我读了《网易云音乐的音讯队列革新之路》，《今日头条在音讯服务平台和容灾体系建设方面的实际与思考》这两篇文章，越是心痒难耐，蛮想去做的是一个真正意义上的音讯治理平台。始终没有什么场景和机会，还是有点惋惜。

最近看了哈罗单车架构专家梁勇的一篇文章《哈啰在分布式音讯治理和微服务治理中的实际》，举荐大家一读。

https://mp.weixin.qq.com/s/N-…

▍ 一扇窗子，开始自研组件

起初，我尝试进一步深刻应用 RocketMQ。

• 仿 ONS 格调封装音讯 SDK；
• 运维侧平滑扩容音讯队列；
• 生产环境 DefaultMQPullConsumer 生产模式尝试

这些做完之后，咱们又自研了注册核心、配置核心，任务调度零碎。设计这些零碎的时候，从 RocketMQ 源码里吸取了很多的养分，尽管当初看来有很多设计不欠缺的中央，代码品质也有待进步，但做完这些零碎后，还是大大晋升我的自信心。

RocketMQ 给我关上了一扇窗子，让我能看到更广大的 Java 世界。对我而言，这就是 <font color=”red”> 开源的盛宴 </font>。

4.2 Kafka: 大数据生态的不可或缺的局部

Kafka 是一个领有高吞吐、可长久化、可程度扩大，反对流式数据处理等多种个性的分布式音讯流解决中间件，采纳分布式音讯公布与订阅机制，在日志收集、流式数据传输、在线 / 离线系统分析、实时监控等畛域有宽泛的利用。

▍ 日志同步

在大型业务零碎设计中，为了疾速定位问题，全链路追踪日志，以及故障及时预警监控，通常须要将各零碎利用的日志集中剖析解决。

Kafka 设计初衷就是为了应答大量日志传输场景，利用通过牢靠异步形式将日志音讯同步到音讯服务，再通过其余组件对日志做实时或离线剖析，也可用于要害日志信息收集进行利用监控。

日志同步次要有三个要害局部：日志采集客户端，Kafka 音讯队列以及后端的日志解决利用。

1. 日志采集客户端，负责用户各类应用服务的日志数据采集，以音讯形式将日志“批量”“异步”发送 Kafka 客户端。
   Kafka 客户端批量提交和压缩音讯，对应用服务的性能影响十分小。
2. Kafka 将日志存储在音讯文件中，提供长久化。
3. 日志解决利用，如 Logstash，订阅并生产 Kafka 中的日志音讯，最终供文件搜寻服务检索日志，或者由 Kafka 将消息传递给 Hadoop 等其余大数据利用系统化存储与剖析。

日志同步示意图：

▍流计算解决

在很多畛域，如股市走向剖析、气象数据测控、网站用户行为剖析，因为数据产生快、实时性强且量大，您很难对立采集这些数据并将其入库存储后再做解决，这便导致传统的数据处理架构不能满足需要。Kafka 以及 Storm、Samza、Spark 等流计算引擎的呈现，就是为了更好地解决这类数据在处理过程中遇到的问题，流计算模型能实现在数据流动的过程中对数据进行实时地捕获和解决，并依据业务需要进行计算剖析，最终把后果保留或者分发给须要的组件。

▍ 数据直达枢纽

近 10 多年来，诸如 KV 存储（HBase）、搜寻（ElasticSearch）、流式解决（Storm、Spark、Samza）、时序数据库（OpenTSDB）等专用零碎应运而生。这些零碎是为繁多的指标而产生的，因其简略性使得在商业硬件上构建分布式系统变得更加容易且性价比更高。通常，同一份数据集须要被注入到多个专用零碎内。例如，当利用日志用于离线日志剖析时，搜寻单个日志记录同样不可或缺，而构建各自独立的工作流来采集每种类型的数据再导入到各自的专用零碎显然不切实际，利用音讯队列 Kafka 版作为数据直达枢纽，同份数据能够被导入到不同专用零碎中。

下图是美团 MySQL 数据实时同步到 Hive 的架构图，也是一个十分经典的案例。

4.3 如何技术选型

2018 年去哪儿 QMQ 开源了，2019 年腾讯 TubeMQ 开源了，2020 年 Pulsar 热火朝天。

音讯队列的生态是如此的凋敝，那咱们如何选型呢？

我想咱们不用局限于音讯队列，能够再扩充一下。简略谈一谈我的认识。

Databases are specializing – the“one size fits all”approach no longer applies —– MongoDB 设计哲学

第一点：先有场景，而后再有适配这种场景的技术。什么样的场景抉择什么样的技术。

第二点：事实往往很简单，当咱们真正做技术选型，并须要落地的时候，技术储备 和老本 是两个咱们须要重点考量的因素。

▍ 技术储备

• 技术团队有无应用这门技术的教训，是否踩过生产环境的坑，以及针对这些坑有没有齐备的解决方案；
• 架构团队是否有成熟的 SDK，工具链，甚至是技术产品。

▍ 老本

• 研发，测试，运维投入人力老本；
• 服务器资源老本；
• 招聘老本等。

最初一点是 人的因素，特地是管理者的因素。每一次大的技术选型考验技术管理者的视线，格局，以及治理智慧。

5 写到最初

我感觉这个世界上没有什么毫无道理的横空出世，真的，如果没有大量的积攒大量的思考是不会把事件做好的。。。
总之，在经验了这部电影当前，我感觉我要学的太多了，这世界上有太多的能人，你认为的极限，弄不好，只是他人的终点。所以只有不停地进取，能力不丢人。那，人能够不上学，但肯定要学习，真的。
—— 韩寒《后会无期》演讲

我学习音讯队列的过程是一直思考，一直实际的过程，尽管我认为的极限，弄不好，只是他人的终点，但至多当初，当我面对这门技术的时候，我的心田充斥了好奇心，同时也是无所畏惧的。

我始终置信：每天学习一点点，比昨天提高一点点就好。

如果我的文章对你有所帮忙，还请帮忙 点赞、在看、转发 一下，你的反对会激励我输入更高质量的文章，非常感谢！