芸兮的博客

Kafka将生产者发布的消息发布到topic中，需要这些消息的消费者可以订阅这些主题。Producer（生产者）: 产生消息的一方。Consumer（消费者）: 消费消息的一方。Broker（代理 / 单个kafka实例）:可以看作是一个独立的Kafka实例。多个Kafka Broker组成一个Kafka Cluster。每个 Broker 中又包含了 Topic 以及 Partition这两个重要的概念Topic（主题）

跳表中采用randomLevel() 方法来实现上述索引建立过程，该方法会随机生成 1~MAX_LEVEL 之间的数（MAX_LEVEL表示索引的最高层数），且该方法有 1/2 的概率返回 1、1/4 的概率返回 2、1/8的概率返回 3，以此类推。从表头节点的最高层索引出发，如果某个节点的下一个元素大于该插入元素（6），则停止，进入下一层索引，依次类推，直至当前层与元素（6）的索引层相同，将节点插入。通过设置定时任务，周期性的抽样key，判断是否过期，如果过期则删除。

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据，完成fork后，读取内存数据并写入RDB文件。分片集群中有多个master，每个master都可以有多个slave节点，master间通过ping监测彼此健康状态，此时就不再需要哨兵机制了。Redis会把一个master的节点映射到 0 - 16383个插槽上，数据的key不是与节点绑定，而是与插槽绑定。多级缓存就是充分利用请求处理的各个环节，分别添加缓存，减轻Tomcat压力，提升服务性能。通过批处理执行，减少网络传输耗时。

使用CountDownLatch来帮助计时，因为我们用到了线程池，线程池的执行是异步的，因此简单使用end - begin，当执行到end时，可能还有未执行完毕的异步线程。基于阻塞队列来处理Redis生成的优惠券订单，有很大的问题：当高并发、高优惠券发放时，阻塞队列的长度却是有限的，而受限于JVM的内存，阻塞队列设置太大，很有可能导致OOM。一个线程查询有库存，尚未扣除库存，另外一个线程也执行了库存查询，由于此外前面的线程还没来得及扣除库存，因此后来的线程也可以执行下单。会等待所有异步线程执行完毕。

为了节省内存空间，我们并不会使用JSON序列化器来处理value，而是统一使用String序列化器，要求只能存储String类型的key和value，当需要存储Java对象时，手动完成对象的序列化和反序列化。另外，假如缓存未命中，需要查询数据库，这个查询数据库的过程也需要调用者提供，因此，函数参数中有一个函数接口类型，从上边存放的对象可以看出，为了实现能够自动反序列化对象，在redis中不仅存入了对象的json序列，还存放了对象的字节码类型名。重建缓存的过程上锁，其他没有拿到锁的线程会阻塞，相互等待。