场景：A系统需要根据业务系统名（比如业务系统就叫KKK）以及时间范围如2022-10-22 10:01到2022-10-22 10:31请求B系统，B系统会返回10:01到10:31这30个分钟的数据；
这个数据需要缓存起来，好下次请求2022-10-22 10:21到2022-10-22 10:51的时候，可以只请求10:32到10:51的数据即可；
因此我们可以将key用KKK:timestamp来保存（timestamp就是比如2022-10-22 10:01这个分钟的timestamp，本来可以用hash，但是hash不支持内部key的过期策略，timestamp在这个场景可以用字符串方便后续用keys判断是否存在哪些分钟的数据，比如KKK:202210221001,KKK:202210221002...KKK:202210221031）；
缓存了上诉30个分钟点数据后，然后来了请求KKK业务系统的2022-10-22 10:21到2022-10-22 10:51的数据，也是先拆成30个key，然后用exists 这三个个key来判断；
但是很遗憾，exists只能判断这些key有多少个是在redis里已经有，而不能判断具体是哪个有哪个没有；
所以这里用keys来判断（keys要慎用，千万不能用keys *这种写法，否则因为redis是单线程处理，这个操作可能耗时十分长导致其他redis请求hung住【可以考虑scan，但是获取的key可能会有重复，需要客户端去重】），即比如要获取的是2022-10-22 10:21到2022-10-22 10:51，那么就可以用keys KKK:2022102210??来获取所有的key（因为这里有匹配模式，我们清楚的知道这里获取的key最多只会有几十个），然后再用这个数据和新的请求要拿到的数据进行对比，得出哪些还没缓存的，再去拿缺失的部分；
当然，也可以直接把2022-10-22 10:21到2022-10-22 10:51转换为key后，直接拿这些数据（32到51的就会返回nil），没有的则再用接口拿剩下的部分；
如果剩下的部分是连续的时间段还好，不连续就看和接口提供方沟通下看能否提供可以设置多个时间段的方式；
标签：10,缓存,key,22,51,redis,KKK,用法,2022 From： https://www.cnblogs.com/silentdoer/p/16815879.html