万俊峰Kevin

前两篇文章我们介绍了缓存使用的各种最佳实践，首先介绍了缓存使用的基本姿势，分别是如何利用go-zero自动生成的缓存和逻辑代码中缓存代码如何写，接着讲解了在面对缓存的穿透、击穿、雪崩等常见问题时的解决

只要我们使用缓存，就必然会面对缓存和数据库间的一致性问题。如果缓存中的数据和数据库的数据不一致，那么业务应用从缓存中读取的数据就不是最新的数据，对业务的影响可想而知。

你有同感吗？ 当大家在开发服务端代码的时候，会不会经常有如下疑问？ 纳闷 MySQL 连接池到底有多少连接？ 每个连接的生命周期持续多久？ 连接异常断开的时候到底是服务端主动断的，还是客户端主动断的？

缓存是高并发服务的基础，毫不夸张的说没有缓存高并发服务就无从谈起。本项目缓存使用Redis，Redis是目前主流的缓存数据库，支持丰富的数据类型，其中集合类型的底层主要依赖：整数数组、双向链表、哈希表

上一篇文章我们把整个项目的架子搭建完成，服务在本地也已经能运行起来了，顺利成章的接下来我们就应该开始写业务逻辑代码了，但是单纯的写业务逻辑代码是比较枯燥的，业务逻辑的代码我会不断地补充到 lerbon

可能大家在工作中都遇到过这样的场景，就是代码更新了但是文档没有更新，从而产生一些问题导致一些扯皮事情的发生。这个问题的本质是服务和文档是割裂的。我们期望的是文档即协议，协议即服务。

微服务架构是一种架构风格，它将一个大的系统构建为多个微服务的集合，这些微服务是围绕业务功能构建的，服务关注单一的业务功能，这些服务具有以下特点： 高度可维护和可测试 松散的耦合 可独立部署。

现代的互联网产品随时都有面对突发大流量的可能，比如我们的商城平时可能业务流量比较平稳，但某一天运营突然说要做一次秒杀活动来推广，如果没有提前做好应对高并发的准备，我们的服务很可能是扛不住的。

goctl 的最早功能是为了解决 GRPC 内网调试问题，大约是在 2019 年，在我们的生产环境中，rpc 是内网隔离的，不可通过外网访问，为了快速 mock 一些线上 RPC client 的请求