Thrift架构简介

Thrift自顶向下可分为四层

1. Server(single-threaded, event-driven)服务器进程调度

2. Processor(compiler generated)RPC接口处理函数分发，IDL定义接口的实现将挂接到这里面

Socket如何通信

在网络中要唯一确定一个进程需要用一个三元组（Protocol，IP，Port），IP地址唯一确定一台主机，再通过协议和端口唯一确定一个进程，这里也可以看到TCP和UDP可以绑定同一个端口。能唯一确定网络中的进程了，便可以利用这个标志在他们之间进行数据交互。

传统哈希算法的局限性

在分布式系统中，通常使用多个节点来保存数据，以提高并发能力和容量，那么如果决定数据保存到哪个节点上呢？一般的做法是通过一个哈希函数对数据key进行计算，然后对节点数量取模，从而得到数据分配的节点： node_id = hash(key) % N 但是这种做法在节点数量N变化的时候，大部分key的计算的节点都会重新分配。如果是应用在分布式缓存，就会导致大规模的缓存失效，引起缓存雪崩。

业务使用Redis做缓存，当有数据更新时，如何保证缓存及时更新

读数据流程

请求到来，业务代码会先查Redis，查不到再去查DB，并将结果写入Redis

写数据方案

1. 先删除缓存，再更新DB

可行性

先删除缓存，再更新DB，下次读请求到来会从数据库查到新的数据更新到缓存中。如果先更新缓存，在更新DB，更新DB失败会导致数据不一致。

为什么要限流？

由于Web服务无法控制调用方的行为，当遇到请求并发量超过系统的容量阈值，会导致服务器资源耗尽从而导致服务异常或宕机，而且某个服务的请求量突增还会影响到上游的服务，如DB或者是其他的公共服务，导致整个系统瘫痪。 可能导致流量突增的原因有以下几点：

全局唯一ID要求

分布式系统中，我们会对一些数据量大的业务进行拆分，如用户表、订单表，当数据量巨大导致数据库性能下降时，通常会进行分库分表，无法利用MySQL的自增ID，那么就需要一个单独的系统来生成全局唯一ID，而且生成的ID要求具有以下特性：