TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。

在写程序的时候，对于频繁访问的数据，我们一般会使用缓存，将数据存储在内存中，方便下次直接在内存中读取，而不需要再去查询数据库或者再进行复杂运算得到。Spring Cache 的使用首先介绍一下Spring提供的Cache接口，并且提供了默认的实现 ConcurrentMapCache，看类名就知道，使用的ConcurrentMap实现。这里主要介绍一下注解形式。（另：个人更推荐接口的方式使用缓存，

mysql 语句中的 not in 是否会走索引，使用explain关键字测试mysql 5.7 发现not in 并不走索隐。

概述：mac上 mvn compile 失败，提示工程jdk版本低，但之前都可以。原因：jdk版本变成14导致 （mac，最近安装了jdk14，java_home默认选择最高的jdk版本）最近写项目，编译的时候发现使用 mvn clean compile 编译失败。报错信息如下：[ERROR] COMPILATION ERROR :[INFO] --------------------------

文章目录程序设计score 设计 (相同积分的排序)缓存数据定时刷新当心缓存击穿之前有做到一个需求, 需要做一个小的排行榜的功能. 然后发现里面涉及到的东西挺多的, 记录一下. 主要包括 zset 使用, 缓存的定时刷新保证数据准确性, 预防缓存击穿.大概需求就是: 排行榜上显示前n个积分最高的用户. 并且相同积分先完成的排在前面. 并且还要能看到自己当前的积分.看到这个需求的时候就想到可以用re

redis也可以用来实现延时消息的功能。理论上也有两种方式订阅 key 过期事件（pub/sub）使用 sorted-set 存储消息，score为消息的过期时间然而实际上订阅过期事件存在诸多问题，所以并不合适：过期事件的不准确，过期时间只在key被删除时才触发，并不是在key过期后就马上删除的pub/sub 不支持持久化，服务器宕机期间的事件会丢失pub/sub 存在丢失的可能，线上使用的red

由于日常开发中遇到几次使用延时消息的场景，而且目前业务中使用到的消息中间件有rabbitmq和kafka，对延时消息的支持都不太理想。其中rabbitmq 延时消息是通过 设置队列ttl+死信exchange实现缺点嘛：每次都得设置两个队列，一个用来实现延时，过期后经死信exchange转到对应的业务队列提供消费。另：rabbitmq有提供延时插件，但缺点较多，如：1. 启动插件要么重启，要么引入

版本：kafka-clients-2.0.1.jarkafkaConsumer 拉取消息的 offset 是存本地的，根据 offset 拉取消息。开启自动提交时，会自动提交 offset 到 broker（在一些场景下会手动检查是否需要提交），防止重启或reblance时 offset 丢失。而本地保存的 offset 是本地拉取到消息时就更新的，所以自动提交的场景下，在消费前过滤掉消息没有影响

redis也可以用来实现延时消息的功能。理论上也有两种方式订阅 key 过期事件（pub/sub）使用 sorted-set 存储消息，score为消息的过期时间然而实际上订阅过期事件存在诸多问题，所以并不合适：过期事件的不准确，过期时间只在key被删除时才触发，并不是在key过期后就马上删除的pub/sub 不支持持久化，服务器宕机期间的事件会丢失pub/sub 存在丢失的可能，线上使用的red