金三银四，我面试了20家互联网公司
最近本渣程序猿加班加到吐，刚到新公司一个月多点。从五月二号（五月一号休息了一天）开始从今天刚好一个月，中间就没有休息过，每天晚上都到9点多甚至好几天都是到11点才能下班，身心俱累。。。借此加班之际，在此发表一下感慨以及最近一段时间的面经～
今年受疫情影响原来的公司行情不好，老板以及领导都希望我们能够出去看看机会，降低一下公司成本。秉持着好聚好散的念头（没要任何赔偿），我们开始正大光明的出去面试。当然这个过程也很艰难！相信2020年金三银四出来找工作的同学一定深有体会。
首先，一开始没有准备的情况下去裸面，基本上就是找脸打，打得啪啪响那种，BOSS上简历一放开蚂蚁金服的就约上了，大厂的魅力一览无余。面试也不和你约时间，基本上一面就是晚上8点左右直接电话过来问你方不方便，一面以后就没然后了。。。
印象最深的一个问题就是：“你的项目用到MySQL和Redis了，如果MySQL和Redis都挂了，如何能够继续提供服务能力？”
我的回答是：“我这边还有一层JVM缓存，能够提供部分热点服务访问能力，无法保证所有服务继续提供能力，更重要的是我们应该去保证MySQL和Redis的高可用。”
redis和数据库都挂了怎么办？？？
当然面试官肯定不太满意我这个回答，各位大佬们你们有更好的答案请评论告诉我。
挂是必然的，这也是我三四年没面试加上没有任何准备的情况下去面试蚂蚁金服，纯属试水。
由浅入深面试连环炮
后来也面试了BOSS直聘、明略科技、车主帮等等大约20多家，也在不断的学习、面试、学习、面试。过程很痛苦，收获也很大。以至于我到新公司之后可以有一堆面试题来面试这边的候选人。
比如这样的连环炮：
- HashSet的底层是用什么来实现的？
- 对HashSet集合装入的对象有什么要求？
- 针对1和2的问题继续延伸到HashMap的实现原理是怎样的？
- HashMap中计算元素的下标公式是什么？hashcode(o) & (size - 1)
- 为什么是size - 1？
- HashMap线程安全吗？
- 线程安全的有哪些？HashTable、ConcurrentHashMap、Colelctions.synchronizedMap()
- HashTable是怎么保证线程安全的？Colelctions.synchronizedMap()呢？ConcurrentHashMap呢？
- 为什么1.8以后用Synchronized来实现ConcurrentHashMap的线程安全，而不再采用分段锁呢？
- synchronized的底层实现原理了解吗？锁升级的过程？与Lock的区别？
- volatile关键字的底层实现原理？CAS的原理？
- 实际开发中有哪些应用场景？
上面的问题其实难者不会，会者不难，说容易也容易，主要是得形成自己的知识体系。
面试题之由浅入深连环炮
针对这个面试连环炮，如果大家需要更细致的答案，可以评论区留言，后面我会给出一份完整的面试题答案，大家关注我即可。
当然也有难的，比如整个面试就一道题！
百亿级别的数据如何能够最优的存储到Redis？请给出你的设计方案。
具体场景示例：我们需要根据用户的资源位banner点击行为来推荐相关的内容，比如用户点击了一个资源位置，则形成uid:bannerId:resourseId这样的一个key，其中uid、bannerId、resourceId等都是一个具体的值，比如uid就是一个类似于uuid的字符串，bannerId是10043，resourceId是1001，则会形成
98654b76b8294833acd198b006b245e8:10043:1001
这样的这个key，然后点击一次就会记录次数为1，点击2次就会记录次数为2。数据记录以后后续推荐时候要判断指定资源位置的点击次数，预计整体数量在百亿级别。
针对以上场景需求，请设计出redis 的存储方案。
这是一个很有意思并且很有挑战的问题，很考验你对redis的掌握能力，如果你没有在平时工作中遇到过，更考验你的临场发挥能力！
首先显然字符串类型是满足我们的场景的，但是如果要存储百亿级别的字符串key，内存空间可想而知，那么有没有其他类型的key能够满足：既要快速读取、又要达到存储空间最小化呢？
哈希键是不是可以呢？如果用哈希键需要避免哪些问题？首先是一个哈希键一定要存储足够多的key，但是不能太多，那多少是最合适的呢？
了解redis底层实现的应该知道当哈希对象可以同时满足以下两个条件时， 哈希对象使用 ziplist 编码：
- 哈希对象保存的所有键值对的键和值的字符串长度都小于 64 字节；
- 哈希对象保存的键值对数量小于 512 个；
不能满足这两个条件的哈希对象需要使用 hashtable 编码。
那么问题来了，百亿级别的数据需要创建多少个哈希key，如果保证每个哈希key的数量不超过512个呢？并且能够均匀分布到所有的哈希key呢？
这里就算是抛砖引玉，感兴趣的同学可以自己想想有没有很好的方案，可以大家一起评论区聊聊。
Redis压缩列表
Redis为了优化数据存储，节约内存，在列表、字典（哈希键）和有序集合的底层实现了使用压缩列表这一优化方案。
压缩列表是一种序列化的数据结构，这种数据结构的功能是将一系列数据与其编码信息存储在一块连续的内存区域，这块内存物理上是连续的。但逻辑上被分为多个组成部分，即节点。目的是为了在一定可控的时间复杂度条件下尽可能的减少不必要的内存开销，从而达到节省内存的效果。需要理解是怎么达到节约内存作用的，还需要去了解压缩列表的存储格式。
这个问题后续我也会出一篇完整的设计方案出来，欢迎大家关注～