02 | 高并发架构设计方法：面对高并发，怎么对症下药？

hash和分段 hash，根据key的hash值定位目标所在地址。hash值1结尾的key在node1，2结尾的在node2等。 数据分布比较平均，但是不方便扩容。因为扩容的话，就要重新编辑hash到node的映射逻辑。 分段，每个node值存储一个范围内的数据。id 100万到101万，在node1，101-102万在node2。 方便扩容，但是数据热点分布可能不均匀。 比如现在分配到node11了id值是111万，数据增加1万增加一个node就好。不需要重新处理映射逻辑。 但问题是，数据热点可能不均匀。比如101-110万都是老用户，现在已经不活跃了。热点用户都在最新的1万个用户。带来的结果就是，处理前10万个用户的node饿死了，而最新的node11可能都已经撑死了。 还是要根据实际业务来决定方案。 另外，以上数据只是随便列一下，实际node存储的数据量肯定远超这个数据量。不要太较真。

一致性Hash算法 + 虚拟节点 还有Redis集群用的哈希槽的方式

由于数据库的性能瓶颈，会不会造成消息队列的消费速度远低于生产速度，导致消息队列崩溃？

首先，我想到的是通过计算key的hash值并取余来找到缓存集群的位置，这个办法简单粗暴，但带来的问题就是当缓存集群进行扩缩容的时候需要将缓存中的所有数据的key重新计算hash值并根据结果迁移数据，这带来了很高的迁移成本。 Redis集群应该是使用一致性哈希算法，将服务器和缓存key全放在一个哈希环上，缓存保存在顺时针找到的最近的服务器上，当扩容时只会损失一台服务器中大约一半的缓存数据，扩展性好很多，哈希不均匀也可以通过虚拟节点的方式得到很大程度的解决。

请教老师几个问题： Q1：Nginx可以认为是一个负载均衡服务器吗？ Nginx一般的用途是“反向代理服务器”，但它也有负载均衡功能，那么，Nginx也可以认为是一个负载均衡服务器吗？ Q2：消息队列可以用在请求和应用服务器之间吗？ 文中消息队列是用在应用服务器和数据库之间，但是，如果请求过多，应用服务器也会处理不过来。请问：消息队列可以用在请求和应用服务器之间吗？比如请求先到外部网关Nginx，那么，Nginx和应用服务器之间，如果请求太多，会引入消息队列吗？ Q3：Mysql是分布式数据库吗？ Q4：微服务网关中怎么会有微服务客户端呢？ A 在“分布式微服务”章节中，微服务网关中有“微服务客户端”。现在流行的SpringCloud体系中，微服务网关是Spring Gateway。Spring Gateway是个独立的组件，它的内部怎么会有各个具体微服务的客户端呢？ B “并将处理结果构造成最后的响应结果返回给用户”，响应结果会是在微服务网关内完成的吗？应该是微服务构造响应，然后微服务网关转发吧。 Q5：微服务架构中不一定是RPC吧。 SpringCloud是用Rest API，不是用RPC吧。

用多个消息队列消费者去消费队列里面的信息时候保存至数据库时，该如何保证消息先后顺序

一般用什么消息队列来接api数据？我想先保存 。其它程序慢慢来获取，然后保存到数据库。 可能有少部分高峰api数据情况

期待后面的精彩课程

期待后面精彩的课程

key 的分片算法：常用两种，range或hash