正确的云计算数据库服务的4个技巧

可以看到，太监只需要给皇帝要做的事情，都编码备案，并固定下处理流程，调整好优先级，皇帝的时间片就可以有效的轮转起来。不至于江山都丢了，还在后宫里风花雪月。

拿网络传输来说，当有了网络数据包，就需要及时处理，否则客户端会超时。这个时候，网卡会立马发出中断请求，CPU就会通过网卡的中断程序去处理这些缓冲区。这都是非常重要的工作。

中断又有硬中断和软中断之分。硬中断是由硬件产生的，比如，像磁盘，网卡，键盘，时钟等。软中断是由当前正在运行的进程所产生的，通常优先级比硬中断低一些。

2. 阻塞会占用CPU么?

代入了皇帝这个身份，我们就可以解释一些平常遇到的，令人疑惑的问题。

我们都见过在Concurent包下面，有一个叫做LinkedBlockingQeque的类。从它的名字就可以看出，这是一个阻塞队列。实际上，它也并不是挂着羊头卖狗肉。

如下面的代码，我们通常把它放在循环中。我对while(true)这种东西是有心理阴影的，因为它有可能会跑满你的CPU。

 

就凭我画的这些密密麻麻的小方块，你就应该给xjjdog点下赞。

现实的CPU，时间片分的会更细，但作为人类你是理解不了那么小的时间间隔的：你可能每天都要花很多时间在吃喝拉撒上，但后宫里总有大部分希望得到你宠幸的妃子，你一点时间片都不留给她。

实在是忙不过来呀!需要一个太监!

1. 中断就是从中断掉

不是让太监来帮你干活的，他没有那个能力。太监是用来给你调度工作的。

比如，有反叛的军队攻到了城外，太监慌慌张张来报告，你就不得不暂停后宫的活动，提着裤子处理首要的问题;再比如，有刚来的妃子频频抛媚眼，但你还有一大堆公文要批，心有余而力不足。

 

现在，请记住你的身份!从进入本篇文章开始，你就是皇帝!三宫六院七十二妃，任君品尝。

人有亲疏远近，事有轻重缓急。作为万岁，你的时间非常宝贵。整个王朝都在你手中运算，方能国泰民安。

为了讨论方便，我们把场景界限在单核CPU上。你就是CPU，当然是仅仅是一颗单核的CPU。

为了让你更好的安排自己的时间，我将你的时间切割成了八九七十二份，每一份都弥足珍贵。

 

总结内容如下

• 1.ActiveMQ 的社区算是比较成熟，但是较目前来说，ActiveMQ 的性能比较差，而且版本迭代很慢，不推荐使用。
• 2.RabbitMQ 在吞吐量方面虽然稍逊于 Kafka 和 RocketMQ ，但是由于它基于 erlang 开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。但是也因为 RabbitMQ 基于 erlang 开发，所以国内很少有公司有实力做erlang源码级别的研究和定制。如果业务场景对并发量要求不是太高(十万级、百万级)，那这四种消息队列中，首选 RabbitMQ。如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。
• 3.RocketMQ 阿里出品，Java 系开源项目，源代码我们可以直接阅读，然后可以定制自己公司的MQ，并且 RocketMQ 有阿里巴巴的实际业务场景的实战考验。RocketMQ 社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些。还有就是阿里出台的技术，你得应对这个技术万一被抛弃，社区黄掉的风险，如果你们公司有技术实力我觉得用RocketMQ 挺好的。
• 4.Kafka 的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms 级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展。同时 Kafka 最好是支撑较少的 topic 数量即可，保证其超高吞吐量。Kafka 唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略。Kafka天然适合大数据实时计算以及日志收集。

四、总结

本文主要对消息队列的历史和基础知识进行梳理和初步介绍，如果有理解不对的地方，望网友批评指出!

五、参考

（编辑：唐山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!