微服务实战系列之Cache（技巧篇）
前言
凡工具必带使用说明书，如不合理的使用，可能得到
“意外收获”。这就好比每个人擅长的领域有所差异，如果放错了位置或用错了人，也一定会让 Leader 们陷入两难之地：“上无法肩负领导之重托，下难免失去伙伴之信任”，最终的结局大致是不欢而散。
通过前序系列文章，博主对主流Cache工具或者系统做了基础总结，旨在通过一文了解每个工具的特点和差异。
我们经常说理论联系实际，如果只知理论不实践，就和赵括一样，未解敌情轻上阵，只能兵败如山倒。为了合理使用Cache，博主决定通过一文，以实践为指导，掌握正确使用缓存之钥。
- 微服务实战系列之MemCache
- 微服务实战系列之EhCache
- 微服务实战系列之Redis
- 微服务实战系列之Cache
- 微服务实战系列之Nginx（技巧篇）
- 微服务实战系列之Nginx
- 微服务实战系列之Feign
- 微服务实战系列之Sentinel
- 微服务实战系列之Token
- 微服务实战系列之Nacos
- 微服务实战系列之Gateway
- 微服务实战系列之加密RSA
- 微服务实战系列之签名Sign
通用
无论什么缓存工具或系统，我们常见一般以
Key-Value为核心定义缓存。
Q1：如何设置Key
我们已经学习到缓存基本都是以Key-Value设置的，那么如何正确的set key就非常关键。Key一般又以字符串（string）见长，所以是不是可以“肆意而为”了？
就像野马之于草原，逍遥狂奔？那自然不行，容易乐极生悲，此刻急需一个套马杆。
Key一般需体现业务含义，一个是可读性，一个是便于检索。
- 含义明确
可以定义具备业务特征的key，比如：center:order:id。 - 长度适中
虽然我们可以自主定义key，显然不宜太长，太长自然消耗带宽和吞吐，以致影响用户体验，甚至宕机。所以建议不要超50个字符。 - 特殊字符
尽量避免甚至拒绝使用特殊字符，比如空格等等无意义的字符。
Q2：如何设置Value
知道了如何设置key，那自然还需掌握如何set value。value一般支持的类型较多，比如字符串（string），集合（比如list）等。该如何合理设置Value呢？
比如Redis官方限制不超512M，那我们可以设置为512M吗？如果想试探试探，可以去play一下，否则以满足性能要求为先。这里重点区分两种数据类型：
如果是字符串类型，单条建议不超10K；
如果是集合类型，子元素不超5000个；
如果未按建议执行，超过会怎么样？比如服务带宽是10M，单个value的大小是1M，那么在有限的网络条件下，QPS/TPS势必严重受损，体验在哪里？缓存的意义在哪里？
Q3：如何设置TTL
TTL（Time To Live）是key-value的过期时间。我们在设计缓存键值对的时候，往往容易一概而论，没有根据实际业务场景需要去设置。TTL设置太长，缓存迟迟不更新，除非强制set；TTL设置太短，缓存还没hit，立即被clear了。如此无法体现缓存的意义和价值。所以合理的设置TTL非常重要。
- 阶梯性
通常我们设置TTL时，需考虑时间分散，有所阶梯化，减少copy。比如T+1，太笼统了。 - 数据有效期
贴近业务场景设置TTL，会让缓存更有效能。任何数据均有一定的时间特性，比如你的征信数据，又比如企业的工商登记数据。
有效的TTL，既能满足业务合理诉求，又能充分利用缓存的高效，如此才是正确的使用方式。
结语
虽然缓存工具基本也就几种，而且各位盆友（包括博主），一上来就用Redis，因为大家都认可。但是仔细分析几种工具的差异和相同点，无非是在不同场景下形成的固定模式。君不见“缓存穿透、缓存击穿、缓存雪崩”三兄弟经常会出现在我们的工作中。所以如果要更好的使用缓存，或者让缓存更上一层楼，还需略微思考一二。
好了，博主今天聊到这里，GoodNight！
