推荐系统的基本架构
推荐系统本质上是一个信息过滤装置，用来在数以万计的海量内容中，筛选出最符合用户兴趣的那部分内容。
基于推荐系统，用户可以发现自己感兴趣的内容，从而提高体验。平台可以自动发现高价值的内容，从而提高效率，并且带来收益。
一个通用的推荐系统架构，就是以物料数据和行为日志为输入，基于预处理以及特征工程之后，得到相应的特征数据，再应用一些算法和模型，来学习特征数据中的隐含知识，最后根据这些隐含知识，来实现精准的个性化推荐。这其中包含了离线计算部分以及线上部分。
推荐系统的Online架构才是真正处理用户请求的服务。当用户的请求到来时，首先经过AB分流模块，在这里对用户的某些特征，应用哈希算法来进行分流，再对分流后的用户应用不同的动态配置，这主要是为了支持不同策略间的对比实验。然后是多路召回阶段，根据用户的某些特征，在多个召回服务以及redis中，并发地获取数据。召回地数据经过滤去重后，就得到了本次推荐的粗略结果。再对这个结果基于模型排序，就得到了基于用户兴趣的个性化推荐结果。最后，基于特定的业务规则，再进行一次重排序。
旧版本线上架构的并发瓶颈问题
旧版本的线上架构如上图所示，主要分为API服务和engine服务，均使用C++编写。API服务主要实现两个接口，一个是推荐feed接口，一个是获取详情接口。recall服务是召回服务，predict服务是模型排序服务。
当http请求到来的时候，首先经过SLB到达一台ECS，然后经过本机上部署的Nginx，转化成FastCGI协议，到达服务程序。Feed流推荐接口，依赖后续的几个服务，但是详情接口只是从redis里取数据。
注册中心选型
注册中心选型类似于其他中间件选型，要考虑的因素非常多。比如说中间件成熟度、社区活跃度、性能等因素。相比之下，注册中心更加关注 CAP 中选 CP 还是选 AP 的问题。
C：Consistency，数据一致性
A：Availability，服务可用性
P：Partition-tolerance，分区容错性
CAP 理论告诉我们，一个分布式系统不可能同时满足数据一致性、服务可用性和分区容错性这三个基本需求，最多只能同时满足其中的两个。——来自《深入浅出分布式原理》
简单来说，选择 CP 就是选了一致性和分区容错性，而选择 AP 就相当于选了可用性和分区容错性。
看上去 P 分区容错性是肯定要选的，那么剩下的就是选 C（一致性） 还是选 A（可用性） 了。那么你要先理解在注册中心选型里面，一致性和可用性究竟哪个更加重要？标准答案是可用性，也就意味着 CP 和 AP 你应该选 AP。
前面我们讨论了客户端容错，那么显然在选择 AP 的情况下，客户端就可能拿到错误的可用节点列表。如果客户端将请求发到错误的可用节点上，就会出现错误，此时客户端自然可以执行容错，换一个可用节点重试。
所以我们要抓住关键词客户端容错进行回答。
在注册中心选型上，重要的是 CAP 原理中应该选择 AP，比如说 Eureka，又或者 Nacos 启用 AP 模式。
万一你公司并没有使用 AP 模型的注册中心，比如说用了 CP 模型的 ZooKeeper，那么你就可以进一步解释，关键词是体量小。
我司之所以用 ZooKeeper，主要是因为我司体量小，集群规模也不大，ZooKeeper 虽然不是 AP 的，但是在这种体量下也够用了。不过我也尝试在公司内部推动看能否换一个中间件，比如说用 Nacos 的 AP 模式。
