Memcached为什么比Redis更能抗热点
Memcached为什么比Redis更能抗热点热点问题的本质热点 key 最主要的问题还是它会导致缓存的流量不均衡，会导致单节点流量过高，无法发挥集群的作用，整个Redis集群能支撑的QPS就退化成了单个实例能支撑的QPS了 Memcached 为什么抗热点性能更好第一个是 Memcached 通过多线程可以利用多核，从而可以显著提升单个实例的吞吐，针对这种流量倾斜的情况可以更好的应对 下图是一个
Caffeine 淘汰策略
Caffeine 淘汰策略使用了 W-TinyLFU 算法，该算法主要有两部分 采用 Count-Min Sketch 算法降低频率信息带来的内存消耗 通过维护一个 PK 机制保障新上的热点数据能够被缓存 Count-Min Sketch 算法该算法首先认为：对于频率统计，我们其实不需要一个精确值。在存储数据时，它首先对 key 进行多种 hash 函数运算，然后在各个 hash 函数对应的二
Memcached 和 Redis 内存管理
Memcached 和 Redis 内存管理传统的 C 语言的 malloc/free 函数是最常用的分配和释放内存的方法，但是这种方法存在着很大的缺陷 不匹配的malloc和free容易造成内存泄露 频繁调用会造成大量内存碎片无法回收重新利用，降低内存利用率 作为系统调用，其系统开销远远大于一般函数调用 MemcachedMemcached默认使用Slab Allocation机制
Redis 能存多少个 Key
数据结构Redis 的键值对存在哪里？ 哈希表 dictEntry 存储的是实际键值对，定义如下 12345678910typedef struct dictEntry { void *key; union { void *val; uint64_t u64; int64_t s64; double d;
MyBatis 缓存设计思想
缓存本质其实就是一个 Map，MyBatis 的缓存最基本的实现是 PerpetualCache，内部使用了 HashMap 来保存数据 缓存一般还有额外的功能比如淘汰策略，最大时长等，如何扩展这些功能？ 扩展类的功能有 2 种，继承和组合，但是 MyBatis 提供了很多功能并且有的是动态组合的，比如容量上限 512，淘汰策略 LRU… 如果是集成的话，那要把所有排列组合都实现一遍，会导致类爆炸
MyBatis 日志设计思想
整体架构用了门面模式，对外暴露 SqlSession 接口 日志模块，采用了适配器模式 如果需要接入多个第三方 SDK 来满足自己的业务需求，但是 SDK 的接口定义与你的业务不兼容，又不能修改第三方 SDK 的代码，可以用适配器设计模式解决 MyBatis 定义了自己 Log 接口，为大部分主流日志框架都实现了 Adapter 适配器 1234567891011121314151617pu
ThreadPoolExecutor
ThreadPoolExecutor线程池对象，如果里面添加了任务，如果不手动调用 shutdown 方法，那么这个对象永远不会被 GC 首先看一下 ThreadPoolExecutor 的源码结构 ThreadPoolExecutor 里面有一个内部类 Worker 这个内部类实现了 Runnable 接口 这个 Worker 类里有一个 runWorker 方法，是保证线程不断运行的原理 12
一致性哈希
一致性哈希问题是为了解决请求负载均衡的 负载均衡算法在多节点分布式系统中，如何有效分配客户端请求以实现负载均衡 轮询算法 加权轮询算法 哈希算法 上面两中对于数据分片就不适用了，比如缓存的 key 分布在不同的节点上，通过哈希函数和取模运算可以将请求映射到特定节点 一致性哈希 一致性哈希算法普通哈希算法存在问题，当节点数增加的时候，需要重新计算映射关系，也要迁移数据 比如一开始有