求职笔记

面试问题：

Devops
1.运维工程师对生产环境有极高的稳定性追求，为了避免单点机房故障，他们往往会建设异地多中心的架构，为了应对故障随时在多城市、多数据中心调配流量。那么，您认为在实现异地多中心架构的过程中，运维工程师们会遇到怎样的技术难题以及其解决思路。

**1.请求路由，会话如何保持
对于请求路由问题,其设计目标在于,让特定用户访问特定的机房,并且可以实现流量分发策略控制,根据IP会话保持。而在于特定业务中,可以根据制定更加复杂的路由规则,利用前端传递来的标签，做路由策略转发。让特定的一些用户在同一个机房中,例如饿了吗，基于附近地区的业务场景，用户,骑手,商家都是在同一个地区。我们通过区分哪些用户在同一个地区,机房按地区进行业务划分。这样商家，用户,骑手的整个核心业务流程会在一个机房中完成，避免了跨机房调用造成延迟,用户下单几分钟,商家才接到订单,骑手接单到派送时间被延长。所以实现一个机房外的路由组件是很有必要的,在机房级别添加一个路由网关。常见的做法就是基于用户ID进行HASH的方式将用户固定在一个机房处理该用户相关的所有业务逻辑。

**2.数据存储服务同步
对于数据存储问题是网络延迟造成最大影响的地方。在常见的解决方案中有多机房单集群,和多机房多集群部署两种.数据的同步可以分为，数据库,缓存,消息队列,session等。在多机房单集群中如何部署？ 及整个系统中存储服务是唯一的一个集群,只有一个master节点.做读写分离设计,所有机房上的服务只能向数据存储集群上的master节点提交写请求,而在读数据时向自己机房上的salve节点提交请求。数据的同步委托给基础组件完成,可以利用数据本身的数据同步方案，但通常无法结合业务特性进行优化提高性能，redis 本身的数据同步在master同步salve时会导致salve不可用，mysql自身的同步方案性能和稳定性都比较差。这时需要团队亲自制定化数据同步组件。来保证多个机房上的数据全量同步。还可以基于消息队列来实现数据同步，但这会导致额外的带宽占用,更可以搭建专用网络线路解决。无论任何的同步方式,在业务端需要对访问数据库的客户端进行重构使其能够支持读写分离。并且为了防止网络延迟，我们可以在客户端做很多事情,第一,双写:多个机房下允许出现多个Master,那么客户端进行封装在底层将写请求发送给多个Master上。第二:双读或回源读,当读取本机房数据没有读到时,去主机房读取或者根据用户请求解析出数据源在哪个机房然后去读取。

***3.是否可跨机房调用？延迟高，占据更多带宽怎么办？
内部RPC等禁止跨主机调用,这样可以防止数据被依赖。避免对专用网络占用更多的带宽。并且当一个机房不可用后不会影响可用机房的业务运行。

***4.一些Devops组建如何支持跨机房部署环境
监控系统,部署系统等如何汇总所有机房的数据,还是将其区分开？ 一般来说,devops组件需要对多机房部署进行升级,增加机房选项。在多机房部署中,日志数据可汇总到统一的数据区处理，日志记录通常异步进行即可。

***5.对于强一致性业务（交易订单/库余额）等，如何保证？
对于强一致数据,应建立多机房单集群的部署模式,使用双读策略。多机房多集群模式,采用双写策略。

***6.如何拆分业务，最大限度避免跨机房延迟?
将业务按照，流量大的业务,核心业务,产生收入的业务进行拆分,优先保证核心业务的多机房部署。将这些业务的整体流程逻辑放在一个机房内处理。列如饿了吗按照 地域信息进行流量切分,将用户下单，卖家接单,骑手接单配送这个核心流程尽量放在一台服务器处理。阿里就按用户ID路由,大型网游可能按照服务区对用户处理流程限定在某个特定机房中。

**7.Devops好坏处
DevOps分工模式的好处很明显：可以减少沟通成本与等待风险，降低正常需求交付所需时间，DEV负责交付，避免交付扯皮。DevOps分工模式的劣势也很突出：每个环节参与角色较多，风险较高，对于业务形态比较多的企业较明显，工具支撑多种业务形态的成本是非常高的，当工具搞不定时，需要人肉补位保证业务发布，如果补位较多，那么DevOps分工就失败了；专业度会有降低，工具只能支持在精确输入的情况下以非常精确的方式完成一件固定的事情，一旦输入有变化而超出规则，该环节就比较麻烦了，工具的专业提升比人要慢的多；DEV权利过大，容易军阀化。

Data Structure and Algorithm

python
https://github.com/taizilongxu/interview_python

plus:

1. 单例模式的应用： 计算token

Network
1.3 Quick Checklist for Choosing HTTP GET or POST

Use GET if:The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

and

Use POST if:
The interaction is more like an order, or The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or o The user be held accountable for the results of the interaction.However, before the final decision to use HTTP GET or POST, please also consider considerations for sensitive data and practical considerations.

MongoDB

1. Advantage
   *Json结构和对象模型接近，开发代码量低
   *Json动态模型更容易相应新业务需求。线上修改数据模式，修改时应用与DB不须下线
   *Json schema规范数据模式
   数据库引擎只在一个存储区读写
   反范式，无关联，优化查询速度
   程序API开发快速
   *Replica Set — 推荐三个结点以上的奇数
   自恢复：当primary节点出问题时，secondary 自动恢复，
   滚动服务：只升级个别节点
   分片结构支持海量数据和无缝扩容

数据结构与算法
贪心，回溯，动态规划比较
相似性：都能解决在一定条件下求最优解的问题，贪心/动态规划能解决的问题 ，回溯都能解决
不同：适合用贪心算法求解的情况，最优子结构，无后效性，贪心选择性（全局最优解可以由当前最优解得出）。适合用动态规划的情况：最优子结构，无后效性，重复子问题。

最优子结构：问题最优解包含子问题最优解
无后效性：第一层含义是，在推导后面阶段的状态的时候，我们只关心前面阶段的状态值，不关心这个状态是怎么一步一步推导出来的。第二层含义是，某阶段状态一旦确定，就不受之后阶段的决策影响
贪心选择性：通过局部最优的选择，能产生全局的最优选择。每一个阶段，我们都选择当前看起来最优的决策，所有阶段的决策完成之后，最终由这些局部最优解构成全局最优解。
重复子问题：不同的决策阶段，达到某个点时可能产生重复的决策值。