代码不光是要实现功能，很重要的一点是代码是写给别人看的，所以我们对代码的质量要有一定的要求，要遵循规范，可以参考go官方的代码review建议。

在分布式应用场景中，分布式事务问题是不可回避的，在目前流行的微服务场景下更是如此。比如在我们的商城系统中，下单操作涉及创建订单和库存扣减操作两个操作，而订单服务和商品服务是两个独立的微服务，因为每个微

上一篇文章中引入了消息队列对秒杀流量做削峰的处理，我们使用的是Kafka，看起来似乎工作的不错，但其实还是有很多隐患存在，如果这些隐患不优化处理掉，那么秒杀抢购活动开始后可能会出现消息堆积、消费延迟、

在前几篇的文章中，我们花了很大的篇幅介绍如何利用缓存优化系统的读性能，究其原因在于我们的产品大多是一个读多写少的场景，尤其是在产品的初期，可能多数的用户只是过来查看商品，真正下单的用户非常少。

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

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

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

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

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