go-zero

为什么需要一致性哈希 首先介绍一下什么是哈希 Hash，一般翻译做散列，或音译为哈希，是把任意长度的输入（又叫做预映射pre-image）通过散列算法变换成固定长度的输出，该输出就是散列值。

微服务集群中，调用链路错综复杂，作为服务提供者需要有一种保护自己的机制，防止调用方无脑调用压垮自己，保证自身服务的高可用。

为什么需要熔断 微服务集群中，每个应用基本都会依赖一定数量的外部服务。有可能随时都会遇到网络连接缓慢，超时，依赖服务过载，服务不可用的情况,在高并发场景下此时调用方不应该继续持续请求故障服务。

go-zero 实战项目：blog 本文以 blog 的网站后台为例，着重介绍一下如何使用 go-zero 开发 blog 的用户模块。

很多连锁故障的场景下的一个常见问题是服务器正在消耗大量资源处理那些早已经超过客户端截止时间的请求，这样的结果是，服务器消耗大量资源没有做任何有价值的工作，回复已经超时的请求是没有任何意义的。

本文带你完整理解万星微服务框架 go-zero 的 restful 框架的实现原理和使用方法，多图详解。

延迟队列：一种带有 延迟功能 的消息队列 延时 → 未来一个不确定的时间 mq → 消费行为具有顺序性 这样解释，整个设计就清楚了。

什么是服务注册发现？ 对于搞微服务的同学来说，服务注册、服务发现的概念应该不会太陌生。 简单来说，当服务A需要依赖服务B时，我们就需要告诉服务A，哪里可以调用到服务B，这就是服务注册发现要解决的问题。

在选择负载均衡算法时，我们希望具备分区和机房调度亲和性 每次选择的节点尽量是负载最低的 每次尽可能选择响应最快的节点 无需人工干预故障节点

在 go-zero 的分布式缓存系统分享里，Kevin 重点讲到过一致性hash的原理和分布式缓存中的实践。本文来详细讲讲一致性hash的原理和在 go-zero 中的实现。

在 Golang 中的 map 结构，在删除键值对的时候，并不会真正的删除，而是标记。那么随着键值对越来越多，会不会造成大量内存浪费？ 首先答案是会的，很有可能导致 OOM。

在重启过程中，会有一段时间不能给用户提供正常服务；同时粗鲁关闭服务，也可能会对业务依赖的数据库等状态服务造成污染。 服务重启或者是重新发布过程中，要做到新旧服务无缝切换，同时可以保障变更服务零宕机时间

本文分析了 go-zero 框架中的指标统计的基础封装、滑动窗口的实现 rollingWindow。

不管是 sqlx，redis，以及 mongo ，等以后可能要支持的数据源类型，底层的池化处理都是通用的；所以当开发者需要池化处理组件时，go-zero 也是提供的。

做架构最难的我认为是懂得取舍（trade-off），寻找最佳收益的平衡点是非常考验综合能力的，缓存的设计也是如此。

对服务来说，我们是不是也可以采用多级缓存的方式来组织我们的缓存数据。同时 redis 的存取都会经过网络IO，那我们能不能把热点数据直接存在本进程内，由进程自己缓存一份最近最热的这批数据呢？

当缓存稳定性问题解决之后，一般我们就会面临数据正确性问题，可能会经常遇到『明明数据更新了，为啥还是显示老的呢？』这类问题。这就是我们常说的『缓存数据一致性』问题了。

我们在流量激增的情况下，服务端哪个部分最有可能会是第一个瓶颈？我相信大部分人遇到的都会是数据库首先扛不住，量一起来，数据库慢查询，甚至卡死。此时，上层服务有怎么强的治理能力都是无济于事的。

最近在看公司的 redis queue 时，发现底层使用的是 go-zero 的 queue 。本篇文章来看看 queue 的设计，也希望可以从里面了解到 mq 的最小型设计实践。

上一篇我们讲了 go-zero 中的并发工具包 core/syncx。从整体分析来看，并发组件主要通过 channel + mutex 控制程序中协程之间沟通。本篇来聊 go-zero 对 Go 中