为什么 Java 面试对中间件就 redis 喜欢问的深入

[yeqizhang]

是因为它太优秀了？

没遇到问 mq 里面的东西，以及 es 等。

其实不知道为什么就喜欢问这个，你问问 juc JVM 线程池 集合之类的底层实现我还比较理解……

突然感觉其实面试来面试去就那些东西了，项目经历很重要，然后学历、稳定性，过了简历关，面试通过后就是个在不在公司的预算之内的问题了。

[yeqizhang]

@wupher 嗯，早点明白就不会先花时间在 zk mq 上去准备面试了

[nicebird]

redis 核心源码 几万行又好懂，进阶题吧。

[wupher]

@yeqizhang 嗯，看个人喜好。

不同价值观下，技术抉择不一样。比如，我有个前同事兼好友，他就是喜欢自己折腾。以队列和分布式锁为例，能用数据库的用数据库，能用 Redis 的就用 Redis 。好处是产品依赖少，坏处是什么都在库上，使用上可能存在总总不尽人意。

我喜好能用 1 行代码解决的，就不要用 2 行，能用中间件解决问题的，我就不自己折腾了。假如公司有 ZK，那我就用 ZK，没有的话，可以建议，嗯，要不我们试试 ETCD ？

但是你解决的问题是不变的，所谓万变不离其宗，那是那些分布式常见的场景。只是我们选择了这个，于是就牺牲了那个，如此而已。以我来说，上次分享就检讨过，代码是省了，中间件是多了。虽然这些中间件原来就有用，但是假如要做云迁移，就会碰到新的麻烦。

所以会就是会，不会也不用沮丧。常见的问题，你碰到过哪些，大致研究过，可以用 A 解决，但是会有 B 代价，说清楚即可。

祝面试好运。

嗯，以个人招聘经验而论。其实面试并不是，“哦，A 问题你会，那你能入职，然后进来就解决 A”。你在工作中总会碰到之前没遇到的问题，碰到之前没见到过的场景。你会怎么解决？常见的策略如何？是否知晓选择的代价？可能还有，价值观大家是否一致？一般大致如此吧。

[wysnylc]

因为要用 redis 和队列解决并发,redis 还能做缓存对性能提高明显
相对来讲其他的东西就可有可无或者没法直观体现在业务上

[luckyyD]

确实优秀。消息队列、分布式锁、页面上的浏览次数、我关注的人、可能认识的人（要用 MySQL 实现这个功能想想都头大）、可能还有别的需要保证业务原子性的东西都可以用它轻松解决。而且 java 需要的就是一个队列，因为高并发和多线程是天然矛盾的，但是这两样 java 都想要，所以 java 做不好的事情就交给能高性能实现队列的工具人去做了。

[namebyrant]

redis 在项目应用度应该是在 mysql 之下，不多问是不可能，持久化 /双写 /集群架构 /可用方案那些实际项目也用得多啊