逍遥子曰：

缓存 1.1 缓存刷新机制，缓存刷新是指什么时候把数据库中的数据加载到缓存 （1） 定期刷新； （2） 缓存命中失败时刷新； 1.2 在有缓存时的数据写入方式： （1） 同步写入，即缓存和数据库同时被写入，即在应用层进行双写操作，这种方式可以有效保证缓存和DB中数据的一致性，由于这种方式即要更新缓存同时还要更改数据库，其访问效率相对较低，适合读多写少的场景； （2） 异步更新机制，在写操

同步与互斥，提到异步必然要涉及到与之对应的另一个词“同步”，而提到“同步”很多人也会联想到另一个词“互斥”，同步是指多个操作之间产生了依赖或者先后顺序关系，互斥是指多个操作需要访问同一个资源，而这个资源又不能让多个操作同时进行，那么这多个操作之间就是互斥关系；同步调用与异步调用，在服务设计时，同步调用是指调用方在发起调用之后必须一直等待直到调用结果返回才能进行后续的操作，异步调用是指调用发起方在发

ID生成器是指能产生不重复ID服务的程序，在后台开发过程中，尤其是分布式服务、微服务程序开发过程中，经常会用到，例如，为用户的每个请求产生一个唯一ID、为每个消息产生一个ID等等，ID生成器也是进行无状态服务开发的重要需求之一。ID生成器有其特殊要求：（1）    产生的ID不能重复，在任何情况下产生的ID都不能重复，例如：在ID生成器程序重启之后，ID生成器产生的新ID不能与重启之前产生

前面介绍的是利用redis快速搭建一个ID生成器服务，这种方式搭建的ID生成器服务还存在一些缺陷：（1）    与应用耦合高，没有对外屏蔽掉内部实现细节，例如redis，用户完全不需要知道ID生成器使用什么产生的ID；（2）    扩展性差，在项目规模较大时，ID的应用会非常多，如果用一组redis无法满足需求时，不方面扩展；下面将对上述的ID生成器进一步改进，改进方式为通过thrif

前面两个ID生成器只是简单的完成功能，如果实际应用到生产环境，则对ID生成器的要求更高，具体包括但不限于以下几点：（1） 产生全局唯一、且单调递增的ID；（2） 任何情况下ID不能重复或者回退；（3） 具备高效率产生ID的能力；（4） 具备提供多种ID的能力；（5） 便于运维管理；        ID生成器整个系统需要分为四个部分：web管理端、IdGen服务、redis以及mysql，其中：（1

原文地址：http://www.linuxvirtualserver.org/zh/lvs1.htmlLVS项目介绍 章文嵩 (wensong@linux-vs.org) 2002 年 3 月本文介绍了Linux服务器集群系统--LVS（Linux Virtual Server）项目的产生背景和目标，并描述了LVS服务器集群框架及目前提供的软件，列举LVS集群系统的特点和一些实际应用，最后，本文谈

原文地址：http://www.linuxvirtualserver.org/zh/lvs2.html本文主要介绍了LVS集群的体系结构。先给出LVS集群的通用体系结构，并讨论了其的设计原则和相应的特点；最后将LVS集群应用于建立可伸缩的Web、Media、Cache和Mail等网络服务。1.引言 在过去的十几年中，Internet从几个研究机构

原文地址：http://www.linuxvirtualserver.org/zh/lvs3.html本文在分析服务器集群实现虚拟网络服务的相关技术上，详细描述了LVS集群中实现的三种IP负载均衡技术（VS/NAT、VS/TUN和VS/DR）的工作原理，以及它们的优缺点。1.前言在 前面文章中，讲述了可伸缩网络服务的几种结构，它们都需要一个前端的负载调度器（或者多个进行主从备份）。我们先分析实

原文地址：http://www.linuxvirtualserver.org/zh/lvs4.html本文主要讲述了LVS集群的IP负载均衡软件IPVS在内核中实现的各种连接调度算法。针对请求的服务时间变化很大，给出一个动态反馈负载均衡算法，它结合内核中的加权连接调度算法，根据动态反馈回来的负载信息来调整服务器的权值，来进一步避免服务器间的负载不平衡。1. 前言 在上一篇文章中，我们主要讲述了

消息与通知本文中的消息是指交给推送系统的待发送字符串；通知是指推送系统内部，通过长连接服务发送给客户端的通知字符串，它只在推送系统内部使用，对于使用推送系统的上层应用无法感知其存在；一、 安全性在推送系统中，安全性最受关注的是长连接的安全管控，以及数据在长连接通道上传输的安全性。举个针对长连接的安全管控的例子：有人知道你的长连接服务的IP地址和端口之后伪造大量的TCP连接，将会对长连接服务器端产生的

**三、 消息推送的工作模式** 常见的消息推送系统的工作模式有：推模式、拉模式以及推拉混合模式三种，在很多推送系统中，采用在线消息直接推送下去，离线消息让客户端拉取，这种方式很容易造成漏消息的问题。本节将介绍几种“特殊定义“的推送模式的特点和应用场景，它们的含义与通常理解的略微有些差异。 在线用户：个人认为在线用户是指网络正常、弱网、网络异常等情况下的用户，这些用户实际上正在使用系统，只是由于

**四、 推送系统的集群化**4.1长连接集群推送系统作为一项基础服务，它需要承载全部在线用户量，对于移动互联网行业，在设计之初的期望目标用户量就非常大，并且用户未来一段时间的增长量通常难以预估，因此要求在设计推送系统时，都要求能够集群化部署、支持动态扩展。那么长连接集群化设计时需要解决那些问题呢？ 个人认为长连接服务需要解决三个问题：路由、管理和动态扩展；另外，如果想要锦上添花，让长连接通道更加

本文是对《架构即未来》一书第7章的总结与思考1. 个人认为书中的过程改为流程更为合适；2. 流程是什么？个人理解：为解决特定问题而形成的套路似的解决办法，只要大家遇到这样的问题，按照流程中的步骤一步步执行，就能确保问题解决。3. 流程能帮助我们做哪些事情？个人理解：（1）规范每个人的操作行为，让问题的解决更为规范、可控；其实每个人都有自己的主管思维和理解，每个人看问题的角度可能都不一样，他们所形成

本文是对《架构即未来》第8章的总结。 1. 书中的的问题翻译为根源更合适。 2. 故障是指造成服务异常的事件，包括停止服务、服务效率降低等；根源是导致故障的原因；同一个根源可能导致多种不同的故障； 3. 解决故障属于紧急事情，找到根源属于重要事情，在时间管理的四象限法制中，紧急事情优先级要高于重要事情；在实际工作中也基本如此：一旦运维发现线上服务出现问题，首先想做的事情就是重启服务，尽量

变更包含广阔的范围，它不仅包括软件的升级还包括对当前环境的任何软、硬件改动，包括配置、操作系统、数据库、防火墙、网络设备等等，对于研发来说，变更最主要的还是版本升级；生产环境的变更是事故发生的主要原因，经验指出，生产环境中的事故，有很大一部分是由于软、硬件的变更而引起；这也与我们的实际工作场景相似，我们在实际工作中，一旦遇到生产环境的问题，首先要问的就是最近有没有谁对系统做过任何改动？例如版本升级

本文是对《架构即未来》一书第11章的总结； 1. 读完本章最大的收获是了解了应该如何评估一个系统的能力以及应该怎样为一个线上系统预留发展空间。在系统上线的时候，我们经常被问到的几个问题就是你的系统能承受多大的用户量？我们当前应该部署多少服务才能承载公司的当前和未来一段时间的业务？ 2. 文中给出若干步骤用于预估系统的预留空间，将其总结如下： （1）确定当前的系统负载量，包括了解系统的组成以

本文是对《架构即未来》一书第12章的总结； 1. 书中总结了一个好的架构应该具备的特点，但是有些特点个人感觉是重复的，中间起来应该有以下3个特点： （1） 具体的、可执行的；好的架构不应有太多虚的东西，它应该能够切实可执行起来用于指导开发； （2） 可度量的；平时最关注的是一个架构所能承载的性能，它应该是可以测试出来； （3） 可达到的；架构设计不应脱离实际，一个很美好但是无法实现的架构是

本文是对《架构即未来》第2章的总结 1. 团队组织的核心就是人员的管理问题 2. 规范和标准对于一个团队来说非常重要，个人理解，它能保障团队成果的质量底线，如果一个团队不能养成遵守规范和标准的习惯，那这个团队的产出成果就会良莠不齐；规范和标准是一个团队由游击队走向正规军的标志； 3. 团队中的任何工作都要职责清晰、明确；如果全凭自觉，靠吃大锅饭的形式，当任务下来的时候就不会有人觉得自己对

本文是对《架构即未来》一书第15章的学习与总结； 1.设计可扩展性的系统的两个关键：水平扩展和为了不可预知；水平扩展是我们服务能扩展的首要条件，未来不可预知是指在设计服务时要做好隔离，做好随时能把一个复杂组件替换掉的准备；这其实还是设计的基本功，要能从一堆复杂问题准确识别出一个组件，确定它的边界，处理好组件内和组件外的通信接口，能识别并设计好一个组件是满足不可预知条件的前提； 2.在对一个组件是

本文是对《架构即未来》一书第16章的总结； 1. 风险管理是提高和保持可用性及可扩展型的最基本和最重要的方面。 2. 测试是预先发现风险并有效降低风险概率的有效方法，但是任何的测试都无法彻底发现所有的风险点； 3. 在AKF中倾向于把风险看成一个“多元化的产品”，将风险分成两部分： （1）风险发生的概率，它有两部分决定： [1] 本次变更（版本升级）的变更量，即这次改动有多大？ [

第17章 性能测试 1. 性能测试是指把负载和用户需求施加在系统上，以测量其相应时间和稳定性的过程，它是为了验证应用能够满足预期的性能目标；一般需要关注响应时间、吞吐量和资源利用率这三类指标； 2. 性能测试的第一步是建立标准，没有标准的测试是没有意义的； 3. 性能测试的环境应该与研发、QA和准生产等环境分开；之所以要把性能测试环境独立开是因为性能测试需要对整个系统施加压力，如果系统中

本文是对《架构即未来》一书第19章的总结； 1. 什么是故障隔离的架构？个人理解，就是一个系统按照其功能划分为几个独立的子模块，子模块之间互不依赖，互不通信；这里的互不通信是指模块之间不要采用同步调用方式，可以采用中间模块转交的异步方式。 2. 故障隔离的架构有什么好处？ （1） 限制故障的影响范围，采用了故障隔离的架构，每个子模块的故障至影响它本身而不会波及到其他模块； （2） 便于故

本文是对《架构即未来》一书第20章的总结； 1. 立方体扩展是指X、Y、Z轴三个方向的扩展方式； 2. X轴扩展，指水平扩展，这种方式简单易于实现，它要求服务必须是无状态的，部署1个和部署多个是一样的，这样可以根据系统当前的业务承载量来部署所需数量的服务实例，一般情况下，该业务需要与服务注册、治理、发现机制相结合，当一个服务A被水平扩展了一个新实例ai时，所依赖它（调用了它）的其他服务C需要