消息处理系统干什么用的

面试官心理分析 其实面试官主要是想看看： 第一，你知不知道你们系统里为什么要用消息队列这个东西？ 不少候选人，说自己项目里用了 Redis、MQ，但是其实他并不知道自己为什么要用这个东西。其实说白了，就是为了用而用，或者是别人设计的架构，他从头到尾都没思考过。 没有对自己的架构问过为什么的人，一定是平时没有思考的人，面试官对这类候选人印象通常很不好。因为面试官担心你进了团队之后只会木头木脑的干呆活儿，不会自己思考。 第二，你既然用了消息队列这个东西，你知不知道用了有什么好处&坏处？ 你要是没考虑过这个，那你盲目弄个 MQ 进系统里，后面出了问题你是不是就自己溜了给公司留坑？你要是没考虑过引入一个技术可能存在的弊端和风险，面试官把这类候选人招进来了，基本可能就是挖坑型选手。就怕你干 1 年挖一堆坑，自己跳槽了，给公司留下无穷后患。 第三，既然你用了 MQ，可能是某一种 MQ，那么你当时做没做过调研？ 你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ，比如 Kafka，甚至都从没调研过业界流行的 MQ 到底有哪几种。每一个 MQ 的优点和缺点是什么。每一个 MQ 没有绝对的好坏，但是就是看用在哪个场景可以扬长避短，利用其优势，规避其劣势。 如果是一个不考虑技术选型的候选人招进了团队，leader 交给他一个任务，去设计个什么系统，他在里面用一些技术，可能都没考虑过选型，最后选的技术可能并不一定合适，一样是留坑。 面试题剖析 为什么使用消息队列 其实就是问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？ 面试官问你这个问题，期望的一个回答是说，你们公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。 先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有 3 个：解耦、异步、削峰。 解耦 看这么个场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃...... mq-1 在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办？要不要重发，要不要把消息存起来？头发都白了啊！ 如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。 mq-2 总结：通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。 面试技巧：你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给它异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个 MQ 去进行系统的解耦。在简历中体现出来这块东西，用 MQ 作解耦。 异步 再来看一个场景，A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求，等待个 1s，这几乎是不可接受的。 mq-3 一般互联网类的企业，对于用户直接的操作，一般要求是每个请求都必须在 200 ms 以内完成，对用户几乎是无感知的。 如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感觉上就是点个按钮，8ms 以后就直接返回了，爽！网站做得真好，真快！ mq-4 削峰 每天 0:00 到 12:00，A 系统风平浪静，每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ，每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的，大量的请求涌入 MySQL，每秒钟对 MySQL 执行约 5k 条 SQL。 一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。 但是高峰期一过，到了下午的时候，就成了低峰期，可能也就 1w 的用户同时在网站上操作，每秒中的请求数量可能也就 50 个请求，对整个系统几乎没有任何的压力。 mq-5 如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ 中。 mq-6 这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决掉。 往期回顾： 【Java问答学堂】1期 为什么使用消息队列？消息队列有什么优点和缺点？Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？ 【Java问答学堂】2期 如何保证消息队列的高可用？ 【Java问答学堂】3期 如何保证消息不被重复消费？或者说，如何保证消息消费的幂等性？ 【Java问答学堂】4期 如何保证消息的可靠性传输？（如何处理消息丢失的问题？） 【Java问答学堂】5期 如何保证消息的顺序性？ 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题？ 【Java问答学堂】7期 如果让你写一个消息队列，该如何进行架构设计？ 【Java问答学堂】8期 es 的分布式架构原理能说一下么（es 是如何实现分布式的啊）？ 【Java问答学堂】9期 es 写入数据的工作原理是什么啊？es 查询数据的工作原理是什么啊？ 【Java问答学堂】10期 es 在数据量很大的情况下（数十亿级别）如何提高查询效率啊？ 【Java问答学堂】11期 es 生产集群的部署架构是什么？每个索引的数据量大概有多少？ 【Java问答学堂】12期 项目中缓存是如何使用的？为什么要用缓存？缓存使用不当会造成什么后果？ 【Java问答学堂】13期 redis 和 memcached 有什么区别？ 【Java问答学堂】14期 redis 都有哪些数据类型？分别在哪些场景下使用比较合适？ 【Java问答学堂】15期redis 的过期策略都有哪些？内存淘汰机制都有哪些？ 【Java问答学堂】16期如何保证 redis 的高并发和高可用？redis 的主从复制原理能介绍

面试官心理分析 其实面试官主要是想看看： 第一，你知不知道你们系统里为什么要用消息队列这个东西？ 不少候选人，说自己项目里用了 Redis、MQ，但是其实他并不知道自己为什么要用这个东西。其实说白了，就是为了用而用，或者是别人设计的架构，他从头到尾都没思考过。 没有对自己的架构问过为什么的人，一定是平时没有思考的人，面试官对这类候选人印象通常很不好。因为面试官担心你进了团队之后只会木头木脑的干呆活儿，不会自己思考。 第二，你既然用了消息队列这个东西，你知不知道用了有什么好处&坏处？ 你要是没考虑过这个，那你盲目弄个 MQ 进系统里，后面出了问题你是不是就自己溜了给公司留坑？你要是没考虑过引入一个技术可能存在的弊端和风险，面试官把这类候选人招进来了，基本可能就是挖坑型选手。就怕你干 1 年挖一堆坑，自己跳槽了，给公司留下无穷后患。 第三，既然你用了 MQ，可能是某一种 MQ，那么你当时做没做过调研？ 你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ，比如 Kafka，甚至都从没调研过业界流行的 MQ 到底有哪几种。每一个 MQ 的优点和缺点是什么。每一个 MQ 没有绝对的好坏，但是就是看用在哪个场景可以扬长避短，利用其优势，规避其劣势。 如果是一个不考虑技术选型的候选人招进了团队，leader 交给他一个任务，去设计个什么系统，他在里面用一些技术，可能都没考虑过选型，最后选的技术可能并不一定合适，一样是留坑。 面试题剖析 为什么使用消息队列 其实就是问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？ 面试官问你这个问题，期望的一个回答是说，你们公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。 先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有 3 个：解耦、异步、削峰。 解耦 看这么个场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃...... 在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办？要不要重发，要不要把消息存起来？头发都白了啊！ 如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。 总结：通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。 面试技巧：你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给它异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个 MQ 去进行系统的解耦。在简历中体现出来这块东西，用 MQ 作解耦。 异步 再来看一个场景，A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求，等待个 1s，这几乎是不可接受的。 一般互联网类的企业，对于用户直接的操作，一般要求是每个请求都必须在 200 ms 以内完成，对用户几乎是无感知的。 如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感觉上就是点个按钮，8ms 以后就直接返回了，爽！网站做得真好，真快！ 削峰 每天 0:00 到 12:00，A 系统风平浪静，每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ，每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的，大量的请求涌入 MySQL，每秒钟对 MySQL 执行约 5k 条 SQL。 一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。 但是高峰期一过，到了下午的时候，就成了低峰期，可能也就 1w 的用户同时在网站上操作，每秒中的请求数量可能也就 50 个请求，对整个系统几乎没有任何的压力。 如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ 中。 这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决掉。 消息队列有什么优缺点 优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰。 缺点有以下几个： 系统可用性降低 系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，ABCD 四个系统还好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整？MQ 一挂，整套系统崩溃，你不就完了？如何保证消息队列的高可用，可以点击这里查看。 系统复杂度提高 硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。 一致性问题 A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。 所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，做好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了 10 倍。但是关键时刻，用，还是得用的。 综上，各种对比之后，有如下建议： 一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了； 后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高； 不过现在确实越来越多的公司会去用 RocketMQ，确实很不错，毕竟是阿里出品，但社区可能有突然黄掉的风险（目前 RocketMQ 已捐给 Apache，但 GitHub 上的活跃度其实不算高）对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。 所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。 如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。

首先你要明确你的定位，不能什么都会一点，也没必要什么都学。请记住一点：什么都会，到了大公司，可能就变成了什么都不会了。如果你想搞前端，html+css？并不能说明什么，其实这是最基本的，也是不需要刻意去学习的，真正的前端工程师是js+css+后端，而且js是非常熟悉才行，需要了解各种流行的框架react、angular、jquery、kissy、nodejs，熟悉他们的源码和实现原理，这只是前端最基本的技能。。对于后端的话，水就比较深了，java、php、cc++等每种语言都有自己的优缺点和适用场景，没有一家独大的，既然创造了这种语言，就有它存在的价值。java是阿里巴巴比较常用的后端语言，包括很多框架都是基于java的。php百度用的比较多、腾讯也在用，而且php适合小型企业使用快速开发。c/c++贴近操作系统，适合用来做基础设施，比较同意出一些高大上的东西，每个大公司应该都有在用的。其实，语言只是一种工具，真正有用的是你可以用这种工具来干什么。比如你可以设计一种大数据处理的框架，然后用某种语言来实现；你还可以想出一种很牛逼的算法，然后用某种语言实现；当然你也可以设计一个很fansy的消息中间件或RPC框架等等。如果你只是会某种语言，对不起，你只能做一个码农。

面试官心理分析 其实这是很常见的一个问题，这俩问题基本可以连起来问。既然是消费消息，那肯定要考虑会不会重复消费？能不能避免重复消费？或者重复消费了也别造成系统异常可以吗？这个是 MQ 领域的基本问题，其实本质上还是问你使用消息队列如何保证幂等性，这个是你架构里要考虑的一个问题。 面试题剖析 回答这个问题，首先你别听到重复消息这个事儿，就一无所知吧，你先大概说一说可能会有哪些重复消费的问题。 首先，比如 RabbitMQ、RocketMQ、Kafka，都有可能会出现消息重复消费的问题，正常。因为这问题通常不是 MQ 自己保证的，是由我们开发来保证的。挑一个 Kafka 来举个例子，说说怎么重复消费吧。 Kafka 实际上有个 offset 的概念，就是每个消息写进去，都有一个 offset，代表消息的序号，然后 consumer 消费了数据之后，每隔一段时间（定时定期），会把自己消费过的消息的 offset 提交一下，表示“我已经消费过了，下次我要是重启啥的，你就让我继续从上次消费到的 offset 来继续消费吧”。 但是凡事总有意外，比如我们之前生产经常遇到的，就是你有时候重启系统，看你怎么重启了，如果碰到点着急的，直接 kill 进程了，再重启。这会导致 consumer 有些消息处理了，但是没来得及提交 offset，尴尬了。重启之后，少数消息会再次消费一次。 举个栗子。 有这么个场景。数据 1/2/3 依次进入 kafka，kafka 会给这三条数据每条分配一个 offset，代表这条数据的序号，我们就假设分配的 offset 依次是 152/153/154。消费者从 kafka 去消费的时候，也是按照这个顺序去消费。假如当消费者消费了 offset=153 的这条数据，刚准备去提交 offset 到 zookeeper，此时消费者进程被重启了。那么此时消费过的数据 1/2 的 offset 并没有提交，kafka 也就不知道你已经消费了 offset=153 这条数据。那么重启之后，消费者会找 kafka 说，嘿，哥儿们，你给我接着把上次我消费到的那个地方后面的数据继续给我传递过来。由于之前的 offset 没有提交成功，那么数据 1/2 会再次传过来，如果此时消费者没有去重的话，那么就会导致重复消费。 如果消费者干的事儿是拿一条数据就往数据库里写一条，会导致说，你可能就把数据 1/2 在数据库里插入了 2 次，那么数据就错啦。 其实重复消费不可怕，可怕的是你没考虑到重复消费之后，怎么保证幂等性。 举个例子吧。假设你有个系统，消费一条消息就往数据库里插入一条数据，要是你一个消息重复两次，你不就插入了两条，这数据不就错了？但是你要是消费到第二次的时候，自己判断一下是否已经消费过了，若是就直接扔了，这样不就保留了一条数据，从而保证了数据的正确性。 一条数据重复出现两次，数据库里就只有一条数据，这就保证了系统的幂等性。 幂等性，通俗点说，就一个数据，或者一个请求，给你重复来多次，你得确保对应的数据是不会改变的，不能出错。 所以第二个问题来了，怎么保证消息队列消费的幂等性？ 其实还是得结合业务来思考，我这里给几个思路： 比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update 一下好吧。比如你是写 Redis，那没问题了，反正每次都是 set，天然幂等性。比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的 id，类似订单 id 之类的东西，然后你这里消费到了之后，先根据这个 id 去比如 Redis 里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个 id 写 Redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了，重复数据插入只会报错，不会导致数据库中出现脏数据。 当然，如何保证 MQ 的消费是幂等性的，需要结合具体的业务来看。 往期回顾： 【Java问答学堂】1期 为什么使用消息队列？消息队列有什么优点和缺点？Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？ 【Java问答学堂】2期 如何保证消息队列的高可用？ 【Java问答学堂】3期 如何保证消息不被重复消费？或者说，如何保证消息消费的幂等性？ 【Java问答学堂】4期 如何保证消息的可靠性传输？（如何处理消息丢失的问题？） 【Java问答学堂】5期 如何保证消息的顺序性？ 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题？ 【Java问答学堂】7期 如果让你写一个消息队列，该如何进行架构设计？ 【Java问答学堂】8期 es 的分布式架构原理能说一下么（es 是如何实现分布式的啊）？ 【Java问答学堂】9期 es 写入数据的工作原理是什么啊？es 查询数据的工作原理是什么啊？ 【Java问答学堂】10期 es 在数据量很大的情况下（数十亿级别）如何提高查询效率啊？ 【Java问答学堂】11期 es 生产集群的部署架构是什么？每个索引的数据量大概有多少？ 【Java问答学堂】12期 项目中缓存是如何使用的？为什么要用缓存？缓存使用不当会造成什么后果？ 【Java问答学堂】13期 redis 和 memcached 有什么区别？ 【Java问答学堂】14期 redis 都有哪些数据类型？分别在哪些场景下使用比较合适？ 【Java问答学堂】15期redis 的过期策略都有哪些？内存淘汰机制都有哪些？ 【Java问答学堂】16期如何保证 redis 的高并发和高可用？redis 的主从复制原理能介绍 为什么使用消息队列？【Java问答学堂】17期 消息队列有什么优点和缺点？【Java问答学堂】18期 Kafka、ActiveMQ、RabbitMQ、RocketMQ的区别？【Java问答学堂】19期 如何保证消息队列的高可用？【Java问答学堂】20期

面试官心理分析 这个问题是肯定要问的，说白了，就是看你有没有实际干过 es，因为啥？其实 es 性能并没有你想象中那么好的。很多时候数据量大了，特别是有几亿条数据的时候，可能你会懵逼的发现，跑个搜索怎么一下 5~10s，坑爹了。第一次搜索的时候，是 5~10s，后面反而就快了，可能就几百毫秒。 你就很懵，每个用户第一次访问都会比较慢，比较卡么？所以你要是没玩儿过 es，或者就是自己玩玩儿 demo，被问到这个问题容易懵逼，显示出你对 es 确实玩儿的不怎么样？ 面试题剖析 说实话，es 性能优化是没有什么银弹的，啥意思呢？就是不要期待着随手调一个参数，就可以万能的应对所有的性能慢的场景。也许有的场景是你换个参数，或者调整一下语法，就可以搞定，但是绝对不是所有场景都可以这样。 性能优化的杀手锏——filesystem cache 你往 es 里写的数据，实际上都写到磁盘文件里去了，查询的时候，操作系统会将磁盘文件里的数据自动缓存到 filesystem cache 里面去。 es 的搜索引擎严重依赖于底层的 filesystem cache，你如果给 filesystem cache 更多的内存，尽量让内存可以容纳所有的 idx segment file 索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高。 性能差距究竟可以有多大？我们之前很多的测试和压测，如果走磁盘一般肯定上秒，搜索性能绝对是秒级别的，1秒、5秒、10秒。但如果是走 filesystem cache，是走纯内存的，那么一般来说性能比走磁盘要高一个数量级，基本上就是毫秒级的，从几毫秒到几百毫秒不等。 这里有个真实的案例。某个公司 es 节点有 3 台机器，每台机器看起来内存很多，64G，总内存就是 64 * 3 = 192G。每台机器给 es jvm heap 是 32G，那么剩下来留给 filesystem cache 的就是每台机器才 32G，总共集群里给 filesystem cache 的就是 32 * 3 = 96G 内存。而此时，整个磁盘上索引数据文件，在 3 台机器上一共占用了 1T 的磁盘容量，es 数据量是 1T，那么每台机器的数据量是 300G。这样性能好吗？ filesystem cache 的内存才 100G，十分之一的数据可以放内存，其他的都在磁盘，然后你执行搜索操作，大部分操作都是走磁盘，性能肯定差。 归根结底，你要让 es 性能要好，最佳的情况下，就是你的机器的内存，至少可以容纳你的总数据量的一半。 根据我们自己的生产环境实践经验，最佳的情况下，是仅仅在 es 中就存少量的数据，就是你要用来搜索的那些索引，如果内存留给 filesystem cache 的是 100G，那么你就将索引数据控制在 100G 以内，这样的话，你的数据几乎全部走内存来搜索，性能非常之高，一般可以在 1 秒以内。 比如说你现在有一行数据。id,name,age .... 30 个字段。但是你现在搜索，只需要根据 id,name,age 三个字段来搜索。如果你傻乎乎往 es 里写入一行数据所有的字段，就会导致说 90% 的数据是不用来搜索的，结果硬是占据了 es 机器上的 filesystem cache 的空间，单条数据的数据量越大，就会导致 filesystem cahce 能缓存的数据就越少。其实，仅仅写入 es 中要用来检索的少数几个字段就可以了，比如说就写入 es id,name,age 三个字段，然后你可以把其他的字段数据存在 mysql/hbase 里，我们一般是建议用 es + hbase 这么一个架构。 hbase 的特点是适用于海量数据的在线存储，就是对 hbase 可以写入海量数据，但是不要做复杂的搜索，做很简单的一些根据 id 或者范围进行查询的这么一个操作就可以了。从 es 中根据 name 和 age 去搜索，拿到的结果可能就 20 个 doc id，然后根据 doc id 到 hbase 里去查询每个 doc id 对应的完整的数据，给查出来，再返回给前端。 写入 es 的数据最好小于等于，或者是略微大于 es 的 filesystem cache 的内存容量。然后你从 es 检索可能就花费 20ms，然后再根据 es 返回的 id 去 hbase 里查询，查 20 条数据，可能也就耗费个 30ms，可能你原来那么玩儿，1T 数据都放 es，会每次查询都是 5~10s，现在可能性能就会很高，每次查询就是 50ms。 数据预热 假如说，哪怕是你就按照上述的方案去做了，es 集群中每个机器写入的数据量还是超过了 filesystem cache 一倍，比如说你写入一台机器 60G 数据，结果 filesystem cache 就 30G，还是有 30G 数据留在了磁盘上。 其实可以做数据预热。 举个例子，拿微博来说，你可以把一些大V，平时看的人很多的数据，你自己提前后台搞个系统，每隔一会儿，自己的后台系统去搜索一下热数据，刷到 filesystem cache 里去，后面用户实际上来看这个热数据的时候，他们就是直接从内存里搜索了，很快。 或者是电商，你可以将平时查看最多的一些商品，比如说 iphone 8，热数据提前后台搞个程序，每隔 1 分钟自己主动访问一次，刷到 filesystem cache 里去。 对于那些你觉得比较热的、经常会有人访问的数据，最好做一个专门的缓存预热子系统，就是对热数据每隔一段时间，就提前访问一下，让数据进入 filesystem cache 里面去。这样下次别人访问的时候，性能一定会好很多。 冷热分离 es 可以做类似于 mysql 的水平拆分，就是说将大量的访问很少、频率很低的数据，单独写一个索引，然后将访问很频繁的热数据单独写一个索引。最好是将冷数据写入一个索引中，然后热数据写入另外一个索引中，这样可以确保热数据在被预热之后，尽量都让他们留在 filesystem os cache 里，别让冷数据给冲刷掉。 你看，假设你有 6 台机器，2 个索引，一个放冷数据，一个放热数据，每个索引 3 个 shard。3 台机器放热数据 index，另外 3 台机器放冷数据 index。然后这样的话，你大量的时间是在访问热数据 index，热数据可能就占总数据量的 10%，此时数据量很少，几乎全都保留在 filesystem cache 里面了，就可以确保热数据的访问性能是很高的。但是对于冷数据而言，是在别的 index 里的，跟热数据 index 不在相同的机器上，大家互相之间都没什么联系了。如果有人访问冷数据，可能大量数据是在磁盘上的，此时性能差点，就 10% 的人去访问冷数据，90% 的人在访问热数据，也无所谓了。 document 模型设计 对于 MySQL，我们经常有一些复杂的关联查询。在 es 里该怎么玩儿，es 里面的复杂的关联查询尽量别用，一旦用了性能一般都不太好。 最好是先在 Java 系统里就完成关联，将关联好的数据直接写入 es 中。搜索的时候，就不需要利用 es 的搜索语法来完成 join 之类的关联搜索了。 document 模型设计是非常重要的，很多操作，不要在搜索的时候才想去执行各种复杂的乱七八糟的操作。es 能支持的操作就那么多，不要考虑用 es 做一些它不好操作的事情。如果真的有那种操作，尽量在 document 模型设计的时候，写入的时候就完成。另外对于一些太复杂的操作，比如 join/nested/parent-child 搜索都要尽量避免，性能都很差的。 分页性能优化 es 的分页是较坑的，为啥呢？举个例子吧，假如你每页是 10 条数据，你现在要查询第 100 页，实际上是会把每个 shard 上存储的前 1000 条数据都查到一个协调节点上，如果你有个 5 个 shard，那么就有 5000 条数据，接着协调节点对这 5000 条数据进行一些合并、处理，再获取到最终第 100 页的 10 条数据。 分布式的，你要查第 100 页的 10 条数据，不可能说从 5 个 shard，每个 shard 就查 2 条数据，最后到协调节点合并成 10 条数据吧？你必须得从每个 shard 都查 1000 条数据过来，然后根据你的需求进行排序、筛选等等操作，最后再次分页，拿到里面第 100 页的数据。你翻页的时候，翻的越深，每个 shard 返回的数据就越多，而且协调节点处理的时间越长，非常坑爹。所以用 es 做分页的时候，你会发现越翻到后面，就越是慢。 我们之前也是遇到过这个问题，用 es 作分页，前几页就几十毫秒，翻到 10 页或者几十页的时候，基本上就要 5~10 秒才能查出来一页数据了。 有什么解决方案吗？ 不允许深度分页（默认深度分页性能很差） 跟产品经理说，你系统不允许翻那么深的页，默认翻的越深，性能就越差。 类似于 app 里的推荐商品不断下拉出来一页一页的 类似于微博中，下拉刷微博，刷出来一页一页的，你可以用 scroll api，关于如何使用，自行上网搜索。 scroll 会一次性给你生成所有数据的一个快照，然后每次滑动向后翻页就是通过游标 scroll_id 移动，获取下一页下一页这样子，性能会比上面说的那种分页性能要高很多很多，基本上都是毫秒级的。 但是，唯一的一点就是，这个适合于那种类似微博下拉翻页的，不能随意跳到任何一页的场景。也就是说，你不能先进入第 10 页，然后去第 120 页，然后又回到第 58 页，不能随意乱跳页。所以现在很多产品，都是不允许你随意翻页的，app，也有一些网站，做的就是你只能往下拉，一页一页的翻。 初始化时必须指定 scroll 参数，告诉 es 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时，否则可能因为超时而失败。 除了用 scroll api，你也可以用 search_after 来做，search_after 的思想是使用前一页的结果来帮助检索下一页的数据，显然，这种方式也不允许你随意翻页，你只能一页页往后翻。初始化时，需要使用一个唯一值的字段作为 sort 字段。 往期回顾： 【Java问答学堂】1期 为什么使用消息队列？消息队列有什么优点和缺点？Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？ 【Java问答学堂】2期 如何保证消息队列的高可用？ 【Java问答学堂】3期 如何保证消息不被重复消费？或者说，如何保证消息消费的幂等性？ 【Java问答学堂】4期 如何保证消息的可靠性传输？（如何处理消息丢失的问题？） 【Java问答学堂】5期 如何保证消息的顺序性？ 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题？ 【Java问答学堂】7期 如果让你写一个消息队列，该如何进行架构设计？ 【Java问答学堂】8期 es 的分布式架构原理能说一下么（es 是如何实现分布式的啊）？ 【Java问答学堂】9期 es 写入数据的工作原理是什么啊？es 查询数据的工作原理是什么啊？

怎么 没人来呀 @中山野鬼###### 1、如果想去掉while（true），可以考虑通知实现； 2、关于自动重连的问题，可以考虑重发送逻辑中抽离出来，采用心跳检测完成； 3、另外发送速率统计部分也应该抽离出来。 4、上多通道要考虑资源使用可控。 5、实在不行按照业务拆分成多模块，用redis 或mq类的扩展一下架构设计； ######回复 @OS小小小 : map =(Map)JSONObject.parse(SendMsgCMPP2ThredPoolByDB.ZhangYi.take()); 换成take，阻塞线程，试试。######回复 @OS小小小 : 1、通知只是告知队列里有新的数据需要处理了； 5、内存队列换成redis队列 实现成本增加，但是可扩展性增加；######1、通知实现的话 ，岂不是 无法保证 最少发送么，又会陷入另一个问题中 是吗？ 或者是我的想法不对么？ 2、嗯，这一块可以这样做。谢谢你 3、速率统计这里 我目前想不到怎么抽离、既可以控制到位，又可以保证不影响。。。 5、redis 是有的 但是 redis的队列的话 跟我这个 没啥区别吧，可能速度更快一点。######while(true) 里面 没数据最起码要休眠啊，不停死循环操作，又没有休眠cpu不高才怪######回复 @OS小小小 : 休眠是必须的，只是前面有数据进来，可以用wait notify 的思路通知，思路就是这样，CountDownLatch 之类多线程通讯也可以实现有数据来就能立即处理的功能######嗯，目前在测试 排除没有数据的情况，所以这一块没有去让他休眠，后面会加进去。 就针对于目前这种情况，有啥好办法吗###### 我的思路是：一个主线程，多个任务子线程。 主线程有一层while(true)，这个循环是不断的扫描LinkedBlockingQueue是否有数据，有则交个任务子线程（也就是你这里定义的线程池）处理，而不是像你这样每个子任务线程都有一个while(true) ######这才是对的做法######嗯，这思路可以。谢谢哈###### 引用来自“K袁”的评论 我的思路是：一个主线程，多个任务子线程。 主线程有一层while(true)，这个循环是不断的扫描LinkedBlockingQueue是否有数据，有则交个任务子线程（也就是你这里定义的线程池）处理，而不是像你这样每个子任务线程都有一个while(true) 正确做法. 还有就是 LinkedBlockingQueue 本身阻塞的，while(true)没问题，主要在于不需要每个发送线程都去block######while（true）不加休眠就会这样###### java 的线程数量大致要和cpu数量一致，并不是越多越快，线程调度是很消耗时间的。要用好多线程，就需要设计出好的多线程业务模型，不恰当的sleep和block是性能的噩梦。利用好LinkedBlockingQueue，队列空闲时读队列的线程会释放cpu。利用消息触发后续线程工作，就没必要使用while(true)来不停的扫描。 ######@蓝水晶飞机 看到你要比牛逼，我就没有兴趣跟你说话了######回复 @不日小鸡 : 我就是装逼怎么啦，特么的装逼装出样子来的，起码也比你牛逼啊。######回复 @蓝水晶飞机 : 你说这话不能掩盖你没有回复我的问题又来回复我导致装逼失败的事实。 那你不是楼主你回复我干什么，还不是回答我的问题。 不要装逼了好么，装多就成傻逼了######回复 @不日小鸡 : 此贴楼主不是你，装什么逼。######回复 @王斌_ : 这些我都知道，我的意思是你这样回复可能会误导其他看帖子的人或者新手，让他们以为线程数就等于CPU数###### 引用来自“OS小小小”的评论 怎么 没人来呀 @中山野鬼 抬举我了。c++ 我还敢对不知深浅的人说，“权当我不懂”，java真心只是学过，没有实际工程上的经验。哈。而且我是c的思维，面对c适合的应用开发，是反对使用线程的。基本思维是，执行模块的生命周期不以任务为决定，同类的执行模块，可根据物理硬核数量，形成对应独立多个进程，但绝对不会同类的任务独立对应多个线程。哈。所以java这类面向线程的设计，没办法参与讨论。设计应用目标不同，系统组织策略自然有异。 唯一的建议是：永远不要依赖工具，特别是所谓的垃圾资源处理回收机制，无论它做的再好，一旦你依赖，必然你的代码，在不久的将来会因为系统设计规模的变大，而变的垃圾。哈。 听不懂的随便喷，希望听懂的，能记得这个观点，这不是我一个人的观点。 ######给100万像素做插值运算进行染色特效，请问单线程怎么做比多线程快？###### @乌龟壳 : 几种方法都可以，第一是按照计算步骤，每个进程处理一个步骤，然后切换共享空间（这没有数据传递逻辑上的额外开销），就是流水思维。第二个是block的思维，同样的几个进程负责相同计算，但负责不同片区。同时存在另一类的进程是对前期并发处理完的工作进行边界处理。 你这个例子体现不出进程和线程的差异的。 如果非要考虑进程和线程在片内cache的差异，如果没记错（错了大家纠正哈），进程之间的共享是在二级缓存之间吧。即便线程能做到一级缓存之间的共享，但对于这种大批量像素的计算，用进程仍然是使用 dma，将数据成块载入一级缓存区域进行处理，而这个载入工作和计算工作是同步的。不会有额外太多的延迟。 你举的这个例子，还真好是我以前的老本行。再说了。像素计算，如今都用专用计算处理器了吧。还用x86或arm来处理，不累死啊。哈。 而且这种东西java不适合，同样的处理器，用c写，基本可以比java快1到2倍。因为c可以直接根据硬件特性和计算逻辑特点有效调度底层硬件驱动方式。而java即便你用了底层优化的官方库，仍然不能保证硬件与计算目标特性的高度整合。 ######回复 @中山野鬼 : 简单来说，你的多个进程处理结果进行汇总的时候，是不是要做内存复制操作？如果是多线程天然就不用，多进程用系统的共享内存机制也不用，问题是既然用了共享内存，和多线程就没区别了。######回复 @乌龟壳 : 两回事哦。共享空间是独立的，而线程如果我没记错，全局变量，包括文件内的（静态变量）是共享的。不同线程共享同一个进程内的变量嘛。这些和业务逻辑相关的东西，每个线程又是独立一套业务逻辑，针对c语言，这样去设计，不是没事找事嘛。面向对象语言，这块都帮你处理好了，自然没有关系。######既然有共享空间了，那你所说的进程和线程实际就是一回事了。###### @乌龟壳   ，数据分两种，一种和算法或处理相关的。一种是待处理的数据。 前者，不应该共享，后者属于数据加工流程，必然存在数据传递或流动，最低成本的传递／流动方式就是共享内存，交替使用权限的思路。 但这仅仅针对待加工的数据和辅助信息，而不针对程序本身。 进程不会搞混乱这些东西特别是（待加工数据的辅助信息），而线程，就各种乱吧。哈。 进程之间，虽然用共享空间，但它本质是数据传递／流动，当你采用多机（物理机器）并发处理时，进程移动到另外一个物理主机，则共享空间就是不能选择的传递／流动方式了。但线程就没有这些概念。 ######回复 @中山野鬼 : 是啊，java天然就不是像C一样对汇编的包装。######@乌龟壳 面向企业级的各种业务，java这些没问题的。而且更有优势，面向计算设备特性的设计开发，就不行了。哈。######回复 @中山野鬼 : 也算各有场景吧，java同样可以多进程可以分布式来降低多线程的风险。java也可以静态编译成目标机器码。总之事在人为。######回复 @乌龟壳 : 高手，啥都可以，低手，依赖这些，就是各种想当然。哈哈。######回复 @中山野鬼 : 那针对java的垃圾回收，这个东西是可以调节它算法的，不算依赖工具吧，哈。不然依赖C语言语法也算依赖工具咯。哈。;-p

金山毒霸+金山卫士。######+10086######回复 @xmut : 是的。金山的软件，装了瑞星防火墙的话，可以看到联网进程N个。当然，瑞星防火墙也不靠谱。免费后更是弹窗、弹游戏窗都来了，甚至很多时候都不拦程序。WPS就处理文字是不错，没用的联网进程真的不爽。######装个WPS默认安装金山快盘、金山卫士一家子，你要比谁更流氓吗？###### 引用来自“归海一刀”的答案 哎，主要是电脑老婆用得多，不像你我都是搞技术的，知道如何去优化电脑、防范病毒。其实，电脑小白是相当多的，如果人人都是做电脑技术出身的就好了。 我用的TX电脑管家一样有这玩意儿。既然你说是技术出身，那你也应该知道，只要内存里有不是你自己写的程序都不安全。你就不怕浏览器收集你的帐号密码？那把浏览器抵制了吧。然后你就不怕操作系统收集你密码？那就洗洗睡吧。虽然我从来不用360的任何软件，但是你这文章，也有些哗众取宠了。 ######+10086######确实有点这意思###### 你要是觉得它不靠谱，干啥要装它 裸奔多年一点事都没有 ######回复 @纵使有花兼明月何堪无酒亦无人 : 有王里######可能黑客一直帮你在杀毒。######也有另外一种可能：你早成为别人的肉鸡，别人在你的电脑上同样裸奔多年一点事也没有，这种事很常见######哎，主要是电脑老婆用得多，不像你我都是搞技术的，知道如何去优化电脑、防范病毒。其实，电脑小白是相当多的，如果人人都是做电脑技术出身的就好了。######国内的大部分软件都会对你电脑硬盘文件进行扫描。别说腾讯就不弹，一会弹拍拍，一会弹会员，一会弹QQ秀，百度就干净？一个竞价排名就能恶心死你，金山杀毒？come on...国内环境如此，商业竞争就是这么残酷，一个村长就能让你残废，还谈什么软件弹窗口..哎 偏激了点国内无干净软件，更无“干净”公司，一旦利益牵扯面过大，你想干净？很难。######回复 @ssn6 : 说得好！顶一下！######一边指责别人的免费软件强奸你，一边又主动去抱360大腿，什么你保护不了自己的老婆你老婆需要的是360, 你自己要用一边用一边骂？一个免费软件还不能在自己的平台推广自己的产品？你请了一个管家看家又整天疑神疑鬼怀疑管家偷你东西？360要你的银行账号有毛用，从你后面夸张的贬低360的回复，你根本就是一个360黑！###### 引用来自“归海一刀”的答案 哎，主要是电脑老婆用得多，不像你我都是搞技术的，知道如何去优化电脑、防范病毒。其实，电脑小白是相当多的，如果人人都是做电脑技术出身的就好了。 目前360的用户量已经锐减一半了, 你纵观整个互联网, 哪家网站会报360的软件更新消息? pcbeta 肯定第一封锁360, cnbeta 那更不用说. 太平洋电脑, 最好在上面不要提360, 否则被喷死. 天空下载, 也仅仅是放了个链接, 不在推荐之列. .......................... 当整个互联网都封杀360时, 流氓也就可以洗洗睡了. ######回复 @ssn6 : 世界上只有两种网站；世界上只有两种软件。。。。######360用户锐减一半的数据来自哪里？GFW还封锁呢，等于中国的人口也一下子就锐减一半？而且你列的这几个网站早就要死不断气了，原来的天空下载早就关了，现在的内容全面抄袭360软件宝库的内容，无非都是做不过360只好羡慕嫉妒恨搞封锁。国人就这样见不得别人好，越成功骂的人、贬低他的人就越多。######回复 @铂金小猪 : +1######这四个网站，除了第三个会偶尔上一下。其他都不上。###### 我也没装。真想不通你不放心干嘛还要安装。 记得N年前的时候，各大报刊评杀软的时候，除了杀毒效果，总是会提到占用内存的问题。而现在中国貌似不提杀毒效果（貌似选择杀软的时候没人会关心国外那个杀软测评，以及考虑360和tx、金山杀毒、防御效果哪个好），也不提占用内存，只关心几个人在用（使用量），好用不好用。 关于好用不好用，很难理解结论是怎么得出来的。装了360上网银安全，不装就不安全（或者没其他防御软件了？比如小红伞、MSE）？开机就报开机花费几秒钟很人性化？ ######回复 @ssn6 : 这都是产品给用户惯得，记得之前看过一个比喻，说一个乞丐去一个人家要饭，年轻人给了他10块钱，后来乞丐每次去年轻人都给他10块钱，后来年轻人结婚了，乞丐又去要饭，年轻人给了他5块钱，乞丐问他为什么这次给5块，年轻人说我娶老婆啦，那五块钱给我老婆省下了，乞丐抽了年轻人一巴掌，说，你把本该属于我的钱给了你老婆。。。。我觉得这个故事就是在说360和如今的用户。。。######记得N年前的时候？N年前没有360的时候，杀毒软件还是老贵老贵的，自从有了360，杀毒软件不再要钱了，穷逼屌丝们也都可以一边用一边骂，不要钱可以免费装逼而已。######回复 @mark35 : U盾还只是天朝的发明产物，这个他们还真可以说是自主研发。别人没有的问题，我们有了，并且我们搞了一个根本不靠谱的方法出来解决，貌似很牛叉的样子。######回复 @地鼠特工队 : 国外网银没见谁必须要装插件的######是啊，国外网银都生活在水深火热之中。我现在生活用MAC，工作用Linux。Windows都是虚拟机的宠物，完全祼奔。######用linux######chrome + adblock plus，清净######禁止插件，妥妥的。###### IE11 + QQ电脑管家 管家重点不是安全工作, 而是给QQ升等级, 你懂的. 其次, 退一万步, 腾讯的道德品格还是给人一种放心. ######回复 @我不叫大脸猫 : 腾讯本来就有QQ医生。公司做大了，谁不想做自己的安全呢？明明是数字出了什么扣扣保镖，还诱惑别人把QQ好友备份到他的服务器，他是什么想法？######+1 腾讯系，还有腾讯的openid也挺方便，不用到处注册######回复 @William : 基本上都是TX软件, QQ音乐, QQ游戏, QQ管家, QQ五笔, QQ浏览器.######+1 反正要用QQ, 索性我也全部TX系, QQ管家, QQ输入法. QQ播放器...######跟tx谈道德啊……另外，你太虚荣了，装个QQ管家是为了升级。 我表示我会装360，但是不是开机启动，也不常用。为了表示支持下360，是360把互联网的一些市场格局打乱了……