张申傲
跟着大明老师一起学习，不只是为了面试，而是系统地梳理下后端的技术体系~
作者回复：加油加油！
2023-06-21
1
程序员花卷
为什么轮询比随机使用得多？
随机其实是不均衡的，可能会出现多次命中同一个服务端节点的情况，导致该服务端节点负载过高，严重的还有可能会产生服务雪崩。轮询可以将请求均衡的分发到每个服务端节点，一个个轮流着来，这样可以避免所有请求打到一个服务端节点的情况。但是轮询也有缺点，比如每个节点的处理能力可能并不一样，一个个轮流着命中的话，一些大请求也有可能会打到处理能力比较弱的节点上，显然不太合理。
作者回复：对的，随机的问题就是这个，尤其是特别倒霉的时候，你连续几次都命中同一个节点。当然，这也可以看做是可控性不强。
后面你对轮询的讨论也很对。一些简单的做法就是用权重来代表节点的处理能力，于是有了加权轮询。但是大请求的问题是非常难以解决，这也是不管选择什么负载均衡算法都有可能遇到偶发性的负载不均衡的根本原因。
之前我见过别人的骚操作，就是在负载均衡里面会检测一下是不是大请求。这个检测非常简单，就是每天计算一批大用户，然后负载均衡器会全量加载这些用户的 ID，在调用特定服务的时候，如果请求的用户 ID 就是这些大用户的 ID，就判定为大请求，而后发送到几台专门的机器上。
不过从本质上来说，它只是避开了大请求的问题，也没有根治。
2023-06-22
11
我好像一点都不像程序员
兄弟们，一起加油，搞起来
作者回复：加油，升职加薪就在眼前！
2023-06-23
程序员花卷
如果注册中心崩溃：
1. 新服务无法将自身信息注册到注册中心
2. 老服务无法将自己的状态信息同步给注册中心，同时客户端也无法从注册中心获取到最新的服务节点列表以做更新。客户端只能继续使用本地的服务节点列表。
3. 客户端无法收到注册中心的通知，那么服务端崩溃信息就无法同步到客户端，这样客户端发起的请求就都会失败，影响系统的使用
作者回复：赞！那么你有什么办法可以进一步解决这个问题？也就是即便在注册中心崩溃的情况下，也能尽可能的提供服务。
2023-06-21
刘峰
赞~对于喜欢各种收集经验、教训的我来说，这门课非常及时，跟了跟了~
作者回复：加油加油
2023-06-21
雨落～紫竹
我想到一个场景 对于大数据场景 数据都是从kafka来的 数据从kafka拉取后 要去获取一些其他数据 而对于一些热点数据 虽然放在redis 但是请求太频繁 网络成为瓶颈 所以放在本地缓存 但是过一段时间 可能导致所以机器 本地缓存的数据基本一致 可以根据对kafka消息进行一定维度的hash发送到指定分区 这样每台机器本地缓存 存的数据都不一样
作者回复：对的！这种根据哈希来选择对应分区的思路可以用于解决缓存、有序性。我之前还用过这个方式来优化过分布式锁。因为同一个业务的都分到了同一个分区上，所以只有一个消费者，也就不需要分布式锁了，差不多都是这个思路
2023-06-26
5
木几丶
回答问题：你可以再举出一个心跳频率、心跳重试机制对系统可用性影响的例子吗？
据我所知，所有根据心跳来判断是否存活的系统都会有因延迟带来的可用性问题，例如Redis主从切换、Nginx反向代理upstream探测，不同系统应对这种可用性问题也有各自的办法，如Redis直接就是服务短暂不可用、Nginx则是选择下一个服务
作者回复：是的。这其实比较没办法，毕竟在分布式情况下，说到底一个节点要想知道另外一个节点的情况，都是只能发个请求。
这种决策背后都是有各自理由的。不过总的来说，我认为就是还是遵循了我这节课说的，要么就是误以为死了，要么就是误以为没死，总之就是难两全。
2023-06-26
1
3.0的A7
获取用户的真实IP，有一下集中方法，分别是应用层方法、传输层方法、网络层方法：
1、应用层方法：X-Forwarded-For
缺点:会被伪造、多个X-Forwarded-For头部、不能解决HTTP和SMTP之外的真实源IP获取的需求
2、传输层方法：利用 TCP Options 的字段来承载真实源 IP 信息、Proxy Protocol、NetScaler 的 TCP IP header
3、网络层：隧道 +DSR 模式
贴一下参考(照抄)来源吧:https://time.geekbang.org/column/article/497864
作者回复：优秀优秀！哈哈哈，能够找准资料也是一种能力！
2023-06-26
20
Johar
限流是目的，熔断和降级是限流后的两种处理方法。
思考题：
1.可以考虑写降级，特别是一些量大不重要的写数据，例如：埋点数据
2.降级：内部观测性数据，比如，埋点数据，服务的观测性数据，内部人员考核数据。
作者回复：很不错的观点。
我个人觉得，可用性是目的，限流是手段，被限流请求可以被熔断或者降级。
不过确实这三个概念意思接近。
2023-06-25
码小呆
我们是夜莺,上面写一个监控脚本,定时去请求对应服务的接口,一旦有服务请求不通过,就在群里实现告警,不过,如果公司的项目都上了prometheus ,一旦流量请求出现问题,就直接在企微群发送告警,这样子应该也是可以的
作者回复：赞！确实可以的。不过面试的时候你还可以讲讲你们公司有没有什么自动处理告警的机制。因为有些故障是可以通过程序来恢复的。
不过你们的真的是服务一不通就告警吗？还是说会有考虑一分钟多少次调不通才告警？
2023-06-24
1
讲师
邓明
前 Shopee 高级工程师，Beego PMC
编辑推荐
看过的人还看了
