nodejs to golang
raft协议简介
node存在三种状态， follower, candidate or leader，如果没有收到相关的entries的话，会从follower变迁到candidate，从而进行leader的一个选举策略
两个时间超时的机制
- 选举超时，如果超时，就会变成candidate，开始进行vote，并发向其他的node
- hearbeat 超时，在vote发送之后，有没有在超时之前收到相关的vote的答复
每次leader发送log时，都会去重置其他follower节点的选举超时时间
这时候，会遇到多个nodes同时发送选举的信息，继续等待，直到有一个拿到master的选举信息，
然后是关于网络隔断的问题，在移除之后，有所谓的值最大的成为最后的master
ApiGateway Limit
限制流量可以使 API 服务在下面的场景中更可靠：
- 某个用户直接或间接造成了流量飙升，我们需要确保对其他用户服务可用。
- 某个用户向 API 服务发送大量请求。 或者更糟的是，某个用户试图恶意冲垮服务器。
- 用户发送了大量低优先级请求，但我们希望确保不会影响其他高优先级请求。 例如，发送大量分析数据请求的用户可能会影响其他用户的关键事务。
- 系统内部产生错误，导致无法处理所有请求，不得不丢弃低优先级的请求。
负载降级
基于使用量的负载降级
我们将流量分为两种类型：关键 API 请求（例如，创建订单）和非关键请求（例如，列出历史订单）。我们有一个 Redis 集群，用于计算当前每种类型的请求数量。
基于worker利用率的负载降级
我们追踪可用的 worker 数量。如果某个 worker 太忙，无法处理分配给它的请求，它会缓慢降级非关键请求，当然是先从测试请求开始。如果降低测试请求的过程中，worker 的处理能力恢复到好的状态，那我们就可以开始缓慢地恢复流量（取消降级）。
我们使用令牌桶算法 [2] 来进行流量限制。该算法有一个集中的桶，为每一个请求分配一个令牌，并不断地缓慢地在桶中放入令牌。 如果桶为空，则拒绝该请求。在我们的例子中，每个用户都被分配一个桶，每当他们产生一个请求时，我们从这个桶中移除一个令牌。
我们通过 Redis 来实现我们的限速器。 既可以自己搭建和运维 Redis 实例，或者如果已经使用 AWS，则可以使用 ElastiCache 这样的托管服务。
外卖的订单分配策略
系统首先通过优化设定配送费以及预计送达时间来调整订单结构；在接收订单之后，考虑骑手位置、在途订单情况、骑手能力、商家出餐、交付难度、天气、地理路况、未来单量等因素，在正确的时间将订单分配给最合适的骑手，并在骑手执行过程中随时预判订单超时情况并动态触发改派操作，实现订单和骑手的动态最优匹配；同时，系统派单后，为骑手提示该商家的预计出餐时间和合理的配送线路，并通过语音方式和骑手实现高效交互；在骑手送完订单后，系统根据订单需求预测和运力分布情况，告知骑手不同商圈的运力需求情况，实现闲时的运力调度。
如何从实际问题中去建模
一个决策优化问题的数学模型，一般包括三个要素：
- 决策变量
- 优化目标
- 约束条件
变量说明：
优化目标：
约束条件:
运筹优化领域中的马尔可夫决策过程描述的就是这样的一类在不确定、信息不完备环境下的序贯决策优化问题。
优化方面，一是问题特征分析，
二是跨学科结合，把订单分配问题转换为图论中的二分图匹配问题来解决。常用的一个方法是先对订单进行打包，将可以由一个人完成的多个订单组成一个任务，再使用二分图匹配算法（匈牙利算法、KM 算法）来解决
即时配送的强不确定性部分，一是延迟调度策略，即在某些场景订单可以不被指派出去，在不影响订单超时的情况下，延迟做出决策；二是系统自动改派策略，即订单即便已经派给了骑手，后台的智能算法仍然会实时评估各个骑手的位置、订单情况，并帮助骑手进行分析，判断是否存在超时风险
线下仿真架构