系统设计

一、背景继上篇【稳定性：对于缩短MTTR的摸索】后，看到一些线上问题应急预案采纳的是回滚计划，然而在大部分牵扯代码场景下，开关技术才是线上问题疾速止血的最佳形式。比方履约平台组的Promise作为下单黄金链路，如遇线上问题的话，采纳通用的回滚形式须要5-10+分钟(500+台机器）并且回滚如果操作不当会减轻问题,而采纳开关技术则是秒级。同时Promise在解决日常迭代需要和稳定性保障方面，性能开关技术同样施展了重要的作用。针对改变范畴大、影响面广的需要，我通常会问上线了最坏状况是什么？应急预案是什么？你带开关了吗？。当然开关也是有老本的，接下来本篇跟大家一起交换下高频公布撑持下的性能开关技术实践与实际联合的点点滴滴。 二、什么是性能开关？性能开关其实就是一个轻量级的动静配置框架，它能够帮忙您在代码中动静治理配置项（你能够了解能够动静干涉代码逻辑走向）。通过应用性能开关，您能够依据须要为利用开启或敞开局部性能。这种办法通常实用于以下场景：设置黑白名单、降级业务性能、流量切量以及大促流动时的动静调整日志级别等。 从代码的角度来讲，每个开关的实质就是一个＂if......else"条件语句块。三、开关用处对于高频率的公布上线来说，开关技术是一种正当的技术手段，被赋予了两种新的用处。 疾速止血：一旦生产环境出了问题，间接找到对应性能的开关选项，将其设置为“敞开”。隔离：行将性能代码隔离在线上执行门路之外，对用户不产生影响。四、开关老本应用开关技术也会带来老本。 首先，每个开关选项起码有两个状态，“开”和“闭”。当咱们在公布之前对软件进行性能验证时，须要思考每个开关在零碎中的状态，有时候甚至要进行组合测试，开关的数量越多，可能就会产生越多组合测试的老本。其次，并不是所有的开关代码都能以优雅的形式实现，给代码的编写和保护都带来了肯定的复杂性，须要仔细设计。最初，开关在零碎中存在的工夫越长，保护它的老本就越高。比方Promise零碎历史起因曾经200多个开关了，没有及时清理当初不敢动。五、开关治理为了可能最大化利用开关带来的益处，并尽可能减少它带来的老本，应该对开关进行系统化的治理，并尽可能遵循以下准则。 在满足业务需要及稳定性的前提下，尽可能少用开关技术。开关实质上是if...else...的语句，它会带来程序的复杂性，尤其是代码设计凌乱、代码模块职责不清晰时，更容易出错。易于治理：软件团队应答开关配置进行对立治理，不便查找和查看状态。开关策略标准化：开关策略是指开关的定义、命名以及如何配置。性能开关应该遵循对立的规范和标准，以便不同团队之间的合作和沟通更加顺畅。目前小组开关命名等也不标准，正在标准化途程中。可扩展性：性能开关应该具备可扩展性，以便在须要时可能轻松地增加新的性能或批改现有的性能。这能够通过应用模块化的设计和凋谢的接口来实现。在确保稳定性的前提下，尽量定期检查和清理不必要的开关项。Promise新性能开关逐渐清理中。6. 安全性：性能开关应该具备足够的安全措施，以确保只有受权的用户能力批改和配置开关状态。此外，性能开关还应该可能避免未经受权的拜访和攻打。如DUCC权限治理及XBP审批治理。 总之，继续交付中应用性能开关技术的准则应该是灵便、牢靠、平安、标准化、自动化、可追溯性和可扩展性的综合体现，以确保零碎可能在不同的环境和需要下保持稳定和高效。 六、典型利用场景开关可分为公布开关、运维开关、A/B试验开关、权限开关。具体利用场景如下： • 性能公布更加灵便：这些开关容许该代码性能提前部署到生产环境中，但性能不失效。比方Promise零碎在下单黄金链路属于上游，很多需要须要零碎先上线，待上游都上线实现后再关上开关进行业务验证。如下图DUCC配置： capactiySwitch.enable=true• 黑白名单性能：黑白名单是罕用的访问控制规定，通过性能开关能够疾速实现黑白名单性能。比方Promise中的KA时效白名单开关。如下图DUCC配置： kaPromiseSwitch.whiteList=010***,011***,012***• 线上验证：零碎上线后，业务须要在生产环境中测试验证，因为生产环境中测试验证存在肯定的危险，性能开关能够配置相干的验证参数组合（比方下单前依据用户pin、下单后订单号、仓库ID等），这样能够在生产环境中不影响其余用户体验的状况上来测试性能，能够更早地发现问题。如下图DUCC配置： jitSwitch.storeId=1-1,1-2,1-3,1-4,****• 运行时动静调整日志级别：在利用运行时动静批改日志级别的性能。比方Promise在618&双11大促峰值期间对日志进行降级（只打印出入参及上游依赖的出入参），TP99从30ms升高到13ms，待大促峰值过后日志调整回来，不便排查。如下图DUCC配置： log4j.logger=info• 降级业务性能：例如在大促到来的时候，能够通过开关将非核心的业务逻辑降级，缩小一些非必要的资源耗费。或者依赖上游JSF问题，如业务有损可承受，也可进行开关降级，通过开关敞开则不调用上游JSF。如下图DUCC配置： commonSwith.fence=true• 切量验证：重构新性能上线后，依据订单号或者pin百分比逐渐切量进行线上验证。如下图DUCC配置： commonSwith.percent=10• 管制客户端行为能力：对于APP来说，这种管制可能意味着客户端周期性地和服务器分割，例如多久同步一次和重试的频率、心跳工夫等 七、开关实际**7.1、**复用型开关比方很多场景发送MQ，目前可通过复用开关来配置发送MQ是异步还是同步形式。而不是每个topic配置一个开关，把雷同的场景对立设置为一个通用的开关。但须要留神通用开关的隔离性差，如果不进行配置校验验证则可能影响其余开关性能。 jmqUtil.asyncTopics=topic1,topic2,topic3,topic4,....比方依赖上游JSF三方接口较多，设计一个复用型开关判断是否须要降级上游 **7.2、**特定工夫失效开关开关个性:开关可配置多个属性值，依据指定工夫失效对应value 应用场景：比方仓库产能审批，之前业务是要求0点开关要失效对应版本，研发须要0点的时候配置，长期这样配置，研发效率低下，并且还须要按时按点对ducc开关进行批改。故设计为一个开关可提前配置好失效工夫和失效的value值。比方上面是产能审批的ducc开关，effectiveTime代表失效日期，version代表对应失效版本。 [ { "effectiveTime": "2023-03-09 12:00", "version": "76" }, { "effectiveTime": "2023-04-20 12:00", "version": "77" }, { "effectiveTime": "2023-05-14 00:00", "version": "78" }]八、总结总的来说，性能开关能够帮忙技术团队更无效地工作，同时还能够改善用户体验，升高公布新性能的危险。 参考： 继续交付2.0业务引领的DevOps精要 作者：京东物流 冯志文 起源：京东云开发者社区 自猿其说Tech 转载请注明起源

作者：vivo 互联网平台产品研发团队 - He Zhichuang、Han Lei手机云服务目前作为每家手机厂商必备的一项根底服务，其服务能力和服务质量对用户来说能够说是十分重要。用户将本人大量的信息数据存储在云端，那咱们的云端服务如何保障服务的稳固和数据的平安，以及如何应答越来越多用户群体的应用？本文将次要介绍 vivo 手机云服务零碎的建设历程。 一、背景简直每家手机厂商都为用户提供了信息存储的云服务能力。通过一个账号，用户能够将手机零碎中的各种罕用的信息备份到云端，以便后续在适合的工夫点查看或复原本身的数据。然而因为用户量级微小，服务在设计零碎的时候须要思考的因素特地多，比方如何保障服务的稳定性，如何保障大文件的传输效率，以及如何保障用户文件的数据持久性等等。 除此之外，随着越来越多的终端用户开始应用vivo云服务，存储和计算的老本也一劳永逸。可能有局部人理解，某些手机厂商的云服务产品年度亏损数亿级别，而次要老本之处来自用户私人文件的存储老本。 另外，在平安方面，云服务在这块须要承当的使命更是重中之重。某些厂商的云服务已经呈现过用户数据泄露，竟然能够通过搜索引擎间接查问到用户的私人文件，这种事件一旦呈现，对企业品牌的打击和影响能够说是十分微小。 如上所述，云服务在建设过程中能够说是困难重重，那么vivo云服务在建设过程中，又是如何兼顾产品性能、资源老本、服务稳定性、数据安全等等诸多因素而进行设计的？且听后文细细合成。 二、产品能力与设计2.1 性能介绍2.1.1 多设施数据同步能力 当今智能设施倒退迅速，各个手机厂商相继推出了PAD、智能手表等设施。因而不同设施之间的数据互通诉求也随之而来，一个帐号实现数据互通。 拿vivo为例，vivo帐号能够同时在vivo手机、vivo PAD、PC上登录，用户能够在手机、PAD、PC上同时对联系人、日历等内容进行编辑，一端编辑，多端可见。 这种多设施数据同步互通就是云服务的一项外围性能。以后云服务反对同步的数据项：联系人、日历、便签、书签、黑名单、蓝牙、WLAN，后续会反对更多的数据项。 2.1.2 整机数据打包备份、恢复能力 手机行业性能更新迭代很快，新的亮点性能会吸引用户购买新机。然而新机购买回来后，各种数据的设置、新增对用户来说是个繁琐、头疼的事件。 为了不便用户将旧手机的数据迁徙到新手机上来，手机厂商提供了一些数据迁徙工具。如我司的互传，新老手机放在一起通过蓝牙能够不便的将数据导入新手机上。然而互传必须要求2个手机在一起，如果用户旧手机不在身边呢？ 此场景下，云服务提供的整机打包性能很好的解决了此痛点。用户在应用旧手机期间，能够关上云服务的整机备份开关，云服务会主动将用户手机数据打成数据包备份至云端。 在用户购买新手机换机时，能够通过云服务疾速抉择老手机的打包数据进行复原，方便快捷。 2.1.3 云盘能力 云盘是一种业余的互联网存储工具，是互联网云技术的产物，它通过互联网为企业和集体提供信息的贮存，读取，下载等服务。具备平安稳固、海量存储的特点。 在vivo云服务中，除了诸如联系人、短信等数据类型内容的备份恢复能力之外，文件类型的云端存储能力，即云盘的能力同样重要。 用户能够将本人本地重要的图片、视频、文档等重要文件备份到云端，以便后续能够在云端后者在其余设施上能够拜访到该文件，同时借助于云盘的能力，用户也能够方便快捷的开释整顿本地空间。 除此之外，云盘还提供了丰盛的文件周边性能，例如压缩文件的在线解压，视频的在线播放，以及文档在线合作等等。 2.2 能力建设2.2.1 多设施数据一致性同步方案设计云服务数据同步的计划采纳的是相似于Git版本治理的概念，次要波及2个行为： 推数据：将本地设施增量数据推送至云端。拉数据：将云端增量数据拉取至本地。次要须要理解的有以下2点： 增量数据辨认；数据抵触解决。（1）增量数据辨认 云服务采纳的是基于数据版本的辨认计划：云端每条数据都有本身的版本号，版本号逐渐递增。 次要同步流程如下图： 如图可见，增量数据同步过程并不简单，整个流程总结如下： 客户端获取云端以后最大的数据版本sv；若客户端本地数据最大版本lv < sv，则证实云端数据有更新，客户端须要拉取云端增量数据；若lv = sv，则客户端判断本地是否存在增量更新数据，若有则将本地增量数据推送到云端。（2）数据抵触解决 数据抵触呈现在多设施同时应用的过程中，同时对同一条数据进行操作，造成数据抵触的状况。 因而同步数据流程须要思考数据抵触的场景。 常见的抵触解决方案有2种：a、主动为用户解决抵触。b、用户手动自行解决抵触。 主动为用户解决抵触个别有以下计划： 以最新的数据批改工夫为准，以批改工夫最迟的设施的数据为准。（多设施时钟无奈对立问题，前面上报的数据可能并不是用户实际上最初批改的）2条数据都保留。（会给用户造成数据反复的错觉，影响体验）用户手动自行解决抵触： 参照git的抵触解决形式，抵触数据展现给用户，由用户自行抉择内容的存留，最初将最终数据推送到云端。 因为云服务对接了很多不同模块的数据：联系人、日程、浏览器书签，不同数据的个性不一样，每种数据的抵触解决的规定也不一样。因而云服务采纳了将抵触数据返回给业务模块，供业务模块自行解决的策略，于业务方采纳上述哪种解决形式，由业务方自行决策。 2.2.2 整机数据打包备份、复原设计云服务采纳的是将本地不同模块的数据打包成文件，上传至云盘的计划。 通过树形构造，将整个包、不同模块、不同模块的数据文件进行关联，复原数据时，通过父包parentId即可获取到所有的数据文件的metaId，进行复原即可。 此计划的长处：不便疾速扩大备份手机其余模块的数据，服务器基本上不须要进行革新。 当然此计划也存在劣势：设施不同模块的数据格式对服务器属于黑盒，服务器难以针对模块的数据做实时的解析和展现。 2.2.3 云盘方案设计绝对于数据我的项目的同步备份，云盘模块次要聚焦的是文件类型的云端存取。 和一般业务模型相比，云盘业务的显著特点是逻辑简单，须要思考的细节很多：例如空间占用、数据安全、大文件传输效率等等，因而整个的零碎设计更加简单。 1、对象存储简介 《对象存储》是由云存储供应商提供的一套基于对象的海量存储服务，个别能够为用户能够提供海量、平安、高牢靠、低成本的数据存储能力。 在vivo云服务的存储逻辑中，用户的图片、视频、音频等文件目前均存储在对象存储服务中。 因为晚期vivo外部并无自建的对象存储能力，故一开始这部分数据均寄存在私有云，随着近两年vivo自建对象存储能力的欠缺，目前私有云数据已齐全迁徙到了自建存储。 2、云盘零碎架构 如上图所示，云盘波及到的周边模块泛滥，然而最外围的还是元数据模块、空间治理模块、文件解决这三个模块，概述如下： 元数据模块：次要用来形容文件的属性，例如文件的名称，文件的大小，媒体文件的长宽低等等。更形象的，元数据模块保留了除了文件实体内容之外的所有信息。 ...

我在实习和工作的过程中发现技术计划的设计这一环节是后端开发散发魅力并且深深吸引我的中央，好的技术计划/架构设计 能够让整个零碎开发的开发者开发更轻松 后续的保护 以及拓展更容易 遇到高并发、各种软硬件生效人为谬误带来的挑战时更牢靠，总而言之，这让我感觉像是在设计本人世界乐高，我对此很有趣味，于是找到了这本书。 数据系统根底这里先给出了一个全文检索服务器的例子（之前《Go In Action》也拿搜寻例子做为开篇，看来文本检索很受大家欢送呀），，假设某个利用蕴含缓存层（例如Memcached)与全文索引服务器（如Elasticsearch或Solr),二者与主数据库放弃关联，通常由利用代码负责缓存、索引与主数据库之间的同步，如下图所示 在设计这个零碎的时候，咱们须要 通过缓存正确地刷新来保障客户端们看到的成果统一；零碎呈现部分生效的时候 保证数据的正确性和完整性零碎产生降级时为客户提供统一良好的体现。负载减少时零碎便于拓展...这本书次要围绕零碎设计的 可靠性可扩展性可维护性开展可靠性硬件故障 在设计零碎思考硬件可靠性的时候 咱们须要思考到 硬盘解体、内存故障、电网停电、网线被拔掉等状况。应答的计划大抵有：1.增加硬件冗余（比方磁盘配置RAID，服务器配置双电源，热插拔CPU，数据中心增加备用电源，发电机等）2.滚动降级（前面会介绍）软件谬误特点工夫值导致服务器解体，比方2012年6月30日产生的闰秒触发的Linux内核bug、依赖服务故障、级联故障等。软件谬误很多时候没方法疾速解决，须要在零碎设计之初认真查看各种交互和依赖，进行全面的测试，过程隔离，提前设计好异样告警。人为谬误经考察发现，运维人员的配置谬误是某大型互联网服务下线的首要起因。所以在零碎设计的时候，咱们能够先假设人是不牢靠的，用最小的出错形式来设计零碎、拆散出最易出错的中央、充沛测试、制订出错是疾速复原机制等。未完待续。。。 参考 Kleppmann M. Designing data-intensive applications: The big ideas behind reliable, scalable, and maintainable systems[M]. " O'Reilly Media, Inc.", 2017.

需要概述：既然设计这个零碎，就要思考对应需要，职工管理系统，顾名思义，是为了治理职工而设计，零碎中最根本的“增删改查”天然少不了。 首先设计头文件首先，咱们定义多个头文件(设立头文件的目标次要是：提供全局变量、全局函数的申明或专用数据类型的定义，从而实现拆散编译和代码复用。 同时，也有利于强化安全性。） 别离如下(以下每个头文件与每种身份的人对应）： boss.h #pragma once#include<iostream>using namespace std;class boss :public worker{public: boss(int id, string name, int post); virtual void showinfo(); virtual string getpost();};employee.h #pragma onceclass employee :public worker{public: employee(int id, string name, int post); virtual void showinfo(); virtual string getpost();};manager.h #pragma onceclass Manager :public Worker{public: Manager(int id, string name, int post); virtual void ShowInfo(); virtual string getPost();};worker manager.h #pragma once#include<iostream>using namespace std;#include"boss.h"#include"manager.h"#include"worker.h"#include"employee.h"#include<fstream>#define TXT "empfine.txt"class worker_manager{public: worker_manager(); void showmenu(); int m_EmpNum; worker** m_EmpArray; void Add_Emp(); void save(); bool_m_File; int get_EmpNum(); void In_emp(); void Show_emp(); int Ison_Emp(int id); void Del_Emp(); void Mod_Emp(); void Find_Emp(); void Sort_Emp(); void Clean_File(); ~worker_manager();};worker.h ...

1. 介绍Drawio是一款开源的流程图绘制工具，领有大量的收费素材和模板，能够绘制流程图，类图，时序图，组织架构图等。 2. 装置Drawio 桌面版分为 installer版 、no-installer版 、网页版（公共/自建）： installer版点击装置后可建设文件后缀名关联（通常应用该版本） 安装包下载地址：https://github.com/jgraph/dra... no-installer版无需装置，点击即用。网页版（公共） 网页版拜访地址：https://www.draw.io/ Drawio 网页版（自建） 从GitHub上下载其源码和公布包。公布包能够部署到本人的Tomcat服务器中，启动后能够在浏览器中应用Drawio。实用于网络环境不佳或局域网内应用。 3. 应用3.1 泳道图3.1.1 横向泳道图特点：只能横向新增泳道，鼠标选中要增加的地位，会呈现蓝色的小箭头，无论是点击横向的还是纵向的，后果都是增加横向泳道。 有两种横向泳道图： 有题目无标题有题目横向泳道图 无标题横向泳道图 3.1.2 纵向泳道图增加形式和特点与横向统一，如下图所示： 3.2 ER图E-R图也称实体-分割图(Entity Relationship Diagram)，提供了示意实体类型、属性和分割的办法，用来形容事实世界的概念模型。 3.2.1 手动创立ER图手动创立ER图流程如下： 抉择 E-R图 手动创立增加 E-R 图 向列表(list)或UML类形态(UML class shape)增加一行，两种形式： 从Entity Relation形态库(shape library)中拖动List Item形态(shape)，而后将其拖放到列表形态(list shape)上以插入新条目。将Item形态从UML形态库中拖放到类形态(class shape)上，以插入新的属性(attribute)或办法(method)。 3.2.2 通过sql创立ER图通过SQL 创立 E-R 图，须要对建表语句 Sql 做一些批改，具体如下： 将主键挪到第一个，其余外键能够紧随在主键前面。主键前面追加PRIMARY KEY关键字，以便后续主动生成款式追加;以示意完结地位留下所有的NOT NULL标记，移除不必要的内容仅保留字段名、字段类型、是否反对为空、正文信息一个 Demo 如下： CREATE TABLE DatabaseName '数据表名'( Id bigint(20) NOT NULL PRIMARY KEY VersionNo bigint(20) '版本号' .....);在Draw.io中部菜单找到+号菜单，找到高级中的从SQL导入 ...

引言置信大家在生活中，特地是最近的双十一流动期间，会收到很多短信，而那些短信都有两个特色，第一个是简直都是垃圾短信，这个特点此处能够忽略不计，第二个特点是链接很短，比方上面这个： 咱们晓得，短信有些是有字数限度的，间接放一个带满各种参数的链接，不适合，另外一点是，不想裸露参数。益处无非以下： 太长的链接容易被限度长度短链接看着简洁，长链接看着容易懵平安，不想裸露参数能够对立链接转换，当然也能够实现统计点击次数等操作那背地的原理是什么呢？怎么实现的？让你实现这样的零碎，你会怎么设计呢？【来自于某鹅场面试官】 短链接的原理短链接展现的逻辑这里最重要的知识点是重定向，先温习一下http的状态码： 分类含意1**服务器收到申请，须要请求者继续执行操作2**胜利，操作被胜利接管并解决3**重定向，须要进一步的操作以实现申请4**客户端谬误，申请蕴含语法错误或无奈实现申请5**服务器谬误，服务器在解决申请的过程中产生了谬误那么以 3 结尾的状态码都是对于重定向的： 300：多种抉择，能够在多个地位存在301：永恒重定向，浏览器会缓存，主动重定向到新的地址302：长期重定向，客户端还是会持续应用旧的URL303：查看其余的地址，相似于301304：未修改。所申请的资源未修改，服务器返回此状态码时，不会返回任何资源。305：须要应用代理能力拜访到资源306：废除的状态码307：长期重定向，应用Get申请重定向整个跳转的流程： 1.用户拜访短链接，申请达到服务器2.服务器将短链接装换成为长链接，而后给浏览器返回重定向的状态码301/302 301永恒重定向会导致浏览器缓存重定向地址，短链接零碎统计拜访次数会不正确302长期重定向能够解决次数不准的问题，然而每次都会到短链接零碎转换，服务器压力会变大。3.浏览器拿到重定向的状态码，以及真正须要拜访的地址，重定向到真正的长链接上。从下图能够看出，的确链接被302重定向到新的地址下来，返回的头外面有一个字段Location就是所要重定向的地址： <img src="https://markdownpicture.oss-cn-qingdao.aliyuncs.com/blog/20211110235518.png" style="zoom:70%;" /> 短链接怎么设计的？全局发号器必定咱们第一点想到的是压缩，像文件压缩那样，压缩之后再解压还原到原来的链接，重定向到原来的链接，然而很可怜的是，这个是行不通的，你有见过什么压缩形式能把这么长的数字间接压缩到这么短么？事实上不可能。就像是Huffman树，也只能对那种反复字符较多的字符串压缩时效率较高，像链接这种，可能带很多参数，而且各种不规则的状况都有，间接压缩算法不事实。 那https://dx.10086.cn/tzHLFw与https://gd.10086.cn/gmccapp/webpage/payPhonemoney/index.html?channel=之间的装换是怎么样的呢？后面门路不变，变动的是前面，也就是tzHLFw与gmccapp/webpage/payPhonemoney/index.html?channel=之间的转换。 理论也很简略，就是数据库外面的一条数据，一个id对应长链接（相当于全局的发号器，全局惟一的ID）： idurl1https://gd.10086.cn/gmccapp/w...这里用到的，也就是咱们之前说过的分布式全局惟一ID，如果咱们间接用id作为参数，貌似也能够：https://dx.10086.cn/1，拜访这个链接时，去数据库查问取得真正的url，再重定向。 单机的惟一ID很简略，用原子类AtomicLong就能够，然而分布式的就不行了，简略点能够用 redis，或者数据库自增，或者能够思考Zookeeper之类的。 id 转换策略然而间接用递增的数字，有两个害处： 数字很大的时候，还是很长递增的数字，不平安，规律性太强了显著咱们平时看到的链接也不是数字的，个别都是大小写字母加上数字。为了缩短链接的长度，咱们必须把id转换掉，比方咱们的短链接由a-z,A-Z,0-9组成，相当于62进制的数字，将id转换成为62进制的数字: public class ShortUrl { private static final String BASE = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"; public static String toBase62(long num) { StringBuilder result = new StringBuilder(); do { int i = (int) (num % 62); result.append(BASE.charAt(i)); num /= 62; } while (num > 0); return result.reverse().toString(); } public static long toBase10(String str) { long result = 0; for (int i = 0; i < str.length(); i++) { result = result * 62 + BASE.indexOf(str.charAt(i)); } return result; } public static void main(String[] args) { // tzHLFw System.out.println(toBase10("tzHLFw")); System.out.println(toBase62(27095455234L)); }}id转 62位的key 或者key装换成为id都曾经实现了，不过计算还是比拟耗时的，不如加个字段存起来，于是数据库变成了： ...

本文是GitHub热门我的项目零碎设计入门的学习笔记第3篇，本篇介绍了StackOverflow的架构。参考文章：Stack Overflow: The Architecture - 2016 Edition。架构图如下: The Internets网络接入即图中最下面那一部分，简略来说，StackOverflow用了CloudFlare的DNS服务器，同时也有本人的DNS服务器。接入了4个ISP服务供应商，路由器也都是主/主复制的模式。 Load Balancers (HAProxy)2台机器，用的是HAProxy做负载平衡，SSL也到这一层终止。机器内存较大用于缓存TLS会话。 Web Tier这一层是11台Web服务器，其中有2台是dev测试的。 Service Tier与Web Tier相似，提供的是外部的Web服务。 Cache & Pub/Sub (Redis)Master/Slave的Redis集群，保留HTTP缓存（之前的服务器中有local缓存）。Protobuf格局。本人开发的Redis客户端。 Search (Elasticsearch)专门给搜寻设置的服务器。每个数据中心都是一个3节点的集群。 Databases (SQL Server)2个SQL集群，外面的各个机器按地区离开。

本文是GitHub热门我的项目零碎设计入门的学习笔记第2篇，本篇记录了零碎架构中常常用到的各个组件。 略过的内容DNSCDN反向代理缓存平安负载平衡常见的负载平衡算法有： 随机最小负载/连贯轮询/加权轮询哈希负载平衡还能够分为四层负载平衡和七层负载平衡，例如AWS提供的NLB和ALB就是这样辨别的。简略来说，四层负载平衡(NLB)工作在TCP那一层，七层负载平衡(ALB)工作在HTTP那一层，所以NLB性能好，能解决所有TCP流量，ALB性能略微差点，只能解决HTTP流量，但能依据HTTP自身的数据进行路由(例如申请的门路、参数、Header不同)。 数据库关系型数据库关系型数据库的一些技术及其细节: 主从复制 主库负责读写，从库只负责读主库在复制数据到从库之前挂掉会造成数据失落从库太多写入提早主库挂掉时，从库晋升为主库须要额定的逻辑主主复制 须要额定的逻辑来决定写入哪个数据库与主从复制一样的问题联结 把数据按不同性能分为多个库，例如用户库、产品库不不便JOIN利用须要额定逻辑来确定读写哪个库分片 一个表分为多个表，如用户表按姓名首字母分为多个SQL语句更简单分片不合理可能导致数据不平衡，例如某个姓的用户很多不不便JOIN非规范化 即不齐全遵循关系型数据库的标准来贮存数据冗余信息来缩小JOIN操作，适宜写少读多的状况SQL调优 慢查问应用索引非关系型数据库BASE实践: Basically Available: 分布式系统在呈现不可预知故障的时候容许损失局部可用性Soft state: 容许存在中间状态Eventually consistent: 数据最终会统一类型： KeyValue型，如redis文档型，如MongoDB列式存储，如HBase图数据库SQL还是NoSQL抉择SQL的起因 结构化数据关系型数据，须要join事务等抉择NoSQL的起因 半结构化数据非关系型数据库高吞吐量等适宜NoSQL的场景 埋点和日志数据热数据元数据等异步工作队列和音讯队列 音讯队列接管，保留和传递音讯，如RabbitMQ、Kafka工作队列接管工作及其相干数据，并执行工作，例如Celery通信略过的内容OSI 7层模型UDP协定RPCRESTHTTP协定HTTP2.0TCP协定序列号和校验码确认包和主动重传流量管制和拥塞管制

本文是GitHub热门我的项目零碎设计入门的学习笔记第1篇，本篇记录了Anki记忆软件和一些根本的实践概念。 工具AnkiAnki是一个卡片式的用于帮忙记忆的软件，它的数据文件是以.apkg结尾的，这种数据文件叫做抽认卡堆。零碎设计入门里提供了抽认卡堆，帮忙咱们记忆一些外围概念，咱们能够在手机上或者电脑上下载一个Anki并关上抽认卡堆。目前零碎设计入门里提供的抽认卡堆都是英文的。 基本概念可扩展性(Scalability)简略来说，如果零碎的性能(Performance)的增长与资源的减少是成比例的，服务就是可扩大的。另一个角度来对待性能与可扩展性： 如果你的零碎有性能问题，对于单个用户来说是迟缓的；如果你的零碎有可扩展性问题，单个用户较快但在高负载下会变慢；CAP实践在一个分布式计算零碎中，只能同时满足下列的两点: 一致性(Consistency)：每次拜访都能取得最新数据但可能会收到谬误响应可用性(Availability): 每次拜访都能收到非错响应，但不保障获取到最新数据分区容错性(Partition Tolerance): 在任意分区网络故障的状况下零碎仍能持续运行这里没有举例子，因而感觉对于之前没有概念的人来说不太好了解，举荐再看一下这篇【CAP 实践常被解释为一种“三选二”定律，这是否是一种误会】。 一致性模式弱一致性最终一致性强一致性可用性模式故障切换 Active-PassiveActive-Active复制 主-从主-主