系统设计

高并发服务端 分布式系统设计概要（上） ======张峻崇 原创。转载请注明出处。====== 又是快一年没写博客了，2013年也只剩尾巴，也不知道今年都忙了些什么。写这篇文章的目的，主要是把今年以来学习的一些东西积淀下来，同时作为之前文章《高性能分布式计算与存储系统设计概要》的补充与提升，然而本人水平非常有限，回头看之前写的文章也有许多不足，甚至是错误，希望同学们看到了错误多多见谅，更欢迎与我讨论并指正。 好了，下面开始说我们今天要设计的系统。 这个系统的目标很明确，针对千万级以上PV的网站，设计一套用于后台的高并发的分布式处理系统。这套系统包含业务逻辑的处理、各种计算、存储、日志、备份等方面内容，可用于类微博，SNS，广告推送，邮件等有大量线上并发请求的场景。 如何抗大流量高并发？（不要告诉我把服务器买的再好一点）说起来很简单，就是“分”，如何“分”，简单的说就是把不同的业务分拆到不同的服务器上去跑（垂直拆分），相同的业务压力分拆到不同的服务器去跑（水平拆分），并时刻不要忘记备份、扩展、意外处理等讨厌的问题。说起来都比较简单，但设计和实现起来，就会比较困难。以前我的文章，都是“从整到零”的方式来设计一个系统，这次咱们就反着顺序来。 那我们首先来看，我们的数据应该如何存储和取用。根据我们之前确定的“分”的方法，先确定以下2点： （1）我们的分布式系统，按不同的业务，存储不同的数据

你看看这标题，忒吸引人了。贵族专制、民主政治和系统设计。这就很使我想知道为啥系统设计能和贵族专制和民主政治联系起来； 贵族专制讲的就是这个概念的完整性系统设计必须由一个人来完成。（个人认为只能一个人.）但是一个人的决定不是任何时候都是正确的，所以这就有了民主政治的出现。在系统设计的时候，概念的完整性系统设计虽然由一个人来构建，但是这个人又不是死的，这种人肯定是善于吸收他人优良的意见和有很强的逻辑性。民主政治恰好给了其他程序猿发表意见的机会，这样就可以使得程序猿的意见可能得到应用。也极大的避免了概念性系统设计出现纰漏;等等 下面这章 “画蛇添足”在未看他的内容的时候我心里差不多已经可以想到这本说想要讲的是什么了。但是事实证明和我所想的还是有一些差别.喜欢其中的一句话：“一个可以开阔结构师眼界的准则是为每个小功能分配一个值：每次改进，功能 x 不超 过 m 字节的内存和 n 微秒。这些值会在一开始作为决策的向导，在物理实现期间充当指南和对所有人的警示！“。 现在来看“为什么巴比伦塔会失败？”,说实话我并不知道他是谁，我还特意去搜了搜这个人的成就和贡献，对这个人有了一定的了解后才继续阅读《人月神话》的； 作者将巴比伦塔失败的原因之一归结于缺乏交流，缺乏组织。而我们能从中的来的教训之一在大型软件开发，要无比重视 交流 的重要性。本书初版之后四十余年的现在

这个作业属于哪个课程 转到 这个作业要求在哪里 转到 团队名称 西柚排课王 这个作业的目标 在需求分析结束后进行详细的系统功能设计以及相应的技术安排分工，以达到更好的项目开发准备 一、团队成员的姓名学号列表 姓名 学号 秦傲明 201731062308 韩浩 201731062319 黄青松 201731062322 王越豪 201731062324 周金柽 201731062321 王雷 201731062313 刘洋 201731062314 黄睿 201731091317 二、本阶段任务分工情况    秦傲明 ：配合进行数据库搭建以及数据收集。完成团队博客作业；并与队员进行项目沟通以及项目进度把控。    韩浩 ：负责前端框架搭建，以及文档作业。    黄青松 ：进行后端算法研究，与负责数据库的队员进行沟通，把控项目整体功能实现。    周金柽 ：负责前端框架搭建，并完成团队答辩ppt。    王越豪 ：协助负责前端框架搭建，并完成文档作业。    刘洋 ：进行数据库建表以及数据收集，并完成文档作业。    王雷 ：进行数据库数据收集，并完成文档作业。    黄睿 ：协助进行后端算法研究，以及数据库数据收集。 三、概要设计 系统大致功能介绍   首先我们的整体系统服务于排课，所有的功能实现需要在选课结果后我们拿到数据后进行排课。所以我们实现的核心功能是在已有课程的基础上

系统级I/O 10.1 UNIX I/O 1.打开文件：一个应用程序要访问一个I/O设备，即要求内核打开相应文件。 2.描述符：内核返回一个小的非负整数，在后续对此文件的所有操作中标识这个文件。 标准输入（描述符0）：STDIN_FILENO 标准输出（描述符1）：STDOUT_FILENO 标准错误（描述符2）：STDERR_FILENO 3.文件位置：从文件开头起始的字节偏移量k。应用程序能够通过执行seek操作，显式设置文件当前位置 10.2 打开和关闭文件 1.flags： O_RDONLY:只读 O_WRONLY:只写 O_RDWR:可读可写 2.mode:mode与umask共同指定了新文件的访问权限位。 3.文件的访问权限位：mode & ~umask umask：umask需要在打开文件前使用函数umask(umask);进行设置 10.3 读和写文件 1.返回：若成功则为实际传送的字节数量；-1表示错误；0表示EOF fd:源文件的描述符 n:拷贝最多n个字节 buf:目标存储器位置 ssize_t write(int fd,const void *buf, size_t n); 2.返回：若成功则为实际写的字节数量；-1表示错误 buf:源存储器位置 n:拷贝最多n个字节 fd:目标文件的描述符 不足值出现情况： 读时遇到EOF 从终端读文本行 读和写网络套接字

　　在我们支付系统设计中，经常会遇到这样一个问题，防止用户重复支付。用户明明只想购买一次，却因为系统问题，导致重复支付，带来额外的物流成本和扯皮退货的运营成本，对商家的信誉和系统的体验很不好。 　　那么实际我们在设计支付系统时，如何来避免这一问题呢。 为什么会出现重复支付 　 1.客户误操作点了两次 　　比如下单的按键在点按之后，在没有收到后端返回之前，按键的状态没有设为已禁用状态，还可以被按。 　 2.支付渠道端返回超时 　　用户在收银台页面点击某个支付方式后，在支付渠道（比如网银或者微信支付宝）上完成付款，但是渠道端返回的异步通知超时，导致系统付款状态尚未更新，用户并不清楚到底订单是否支付成功，而导致再次支付。 如何防止重复支付提交 　　在我们实际支付系统设计中，我们系统设计人员经常无法区分商品订单和支付订单之间的关系，经常混为一谈。所以本文谈论的是支付订单的防重复，商品订单的防重复需要另外讨论（包括用户误操作、客户端和后台时延、以及支付和商品订单状态更新不同步等问题）。 　　对于支付重复提交的处理，一般有两种主流的办法：一种是京东收银台的，京东允许客户对一笔商品订单做多次支付，而对于第二笔以上的支付，走退款流程；另外一种是对订单幂等要求比较高的银行收银台，往往是要求商品订单状态和支付订单状态强一致性。 　　这里，我们重点讨论第二种方式，保持支付订单的幂等性来防止重复支付。 　

前言 从单体架构到SOA架构，再到微服务架构，除了软件开发本身的技术驱动外，背后还有管理方法论的推动。这个视角是我担任技术管理职位之后才逐渐意识到的。本文就来分享一下我对系统架构与技术管理的一些思考，其背后的理论基础就是著名的『康威定律』。 康威定律缘起 1968年，马尔文·康威（Melvin Conway）在其论文《How Do Committees Invent?》阐述了系统设计与组织架构的内在联系。1975年，Fred Brooks在他著名的《人月神话》书中引用了这篇论文的结论，并命名为康威定律。Conway的论文原文表述如下： Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. 中文意思是设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。可以简洁地表述为『组织架构等同系统设计』。下图是亚马逊、Google等知名互联网公司的组织架构抽象图，很好地说明了这一概念。 2015年，来自哈佛商学院和 MIT 的研究团队，用实际的研究和调查，证明了康威定律的普适性。在其发表的论文《Exploring the Duality between

系统设计与规划--一点总结 转自： http://www.cnblogs.com/qingteng1983/archive/2010/07/25/1784528.html 有感于目前公司的一个项目产品中遇到的一些问题，结合着自己的设计与开发经历，总结一下系统设计与规划的必要性和知识点，作为将来设计的参考，也与大家一同探讨系统设计中要注意的各方面。 产品简介： 该产品是一个WebGIS系统，历经2-3年的开发与实施，目前准备从项目升级为产品，但是在项目实 施中暴露出大量问题，使得实施人员和开发人员狼狈不堪，离产品要求还有较大差距，所以领导层意识到问题的严重性，要求进行改造，并让我做一些技术指导和设 计上的把关。作为一个未曾参与开发的其它小组成员，以旁观者的身份进行观察，发现 目前存在的一些问题： 1. 系统功能不稳定，很多基本功能都会偶尔冒出问题，搞得实施人员提心吊胆，对产品没信心。 2. 系统中出现一些低级错误，比如分页功能出错，上传文件的功能没有文件类型过滤...诸如此类，有失专业水准。 3. 只支持IE浏览器，但对IE6和IE8不支持，只能强迫用户安装IE7，并且要用兼容模式浏览，使用很不方便。 4. 因为不同项目的需求不同，客户的界面风格喜好不一样，所以为各个项目的修改和定制花费大量精力。 5. 在修正客户所提的bug过程中，时常引入另外的bug，把原本好的功能弄出错误。 6

前端系统设计 前端三大件：html、css、js，万变不离其中，不管我们使用的是vue、react、angular还是其他什么，都是要提高我们代码的复用性、可读性、可维护性以及可拓展性。 html 语义化的标签，在不借助任何前端框架的情况下， < header > < section > < nav > < ul > < li > < a href = " # " > 菜单1 </ a > </ li > < li > < a href = " # " > 菜单2 </ a > </ li > </ ul > </ nav > </ section > </ header > 这种方式能有一定的可读性，但在更为复杂的页面的结构之下是不是缺失了可读性和可维护性。 组件化控制html结构，运用组件化架构的方式将一个页面划分为多个组件，包括项目级组件（在整个范围都会使用到的）和页面级组件 组件化的优势点： 提高复用性 举例：按钮组件，整个系统的按钮风格应该大致差不错，拥有的行为也差不多。我们将按钮单独抽离出来作为一个单独的组件，它拥有自己独立的结构、样式、行为，遵从单一职责、开闭原则，当我们在构建下一个页面的时候，直接引入既可以使用，达到了提高复用性的效果。 提高可读性 举例：我们一个页面有很多的内容，以上图来看，我们这个页面的结构大致是，头部，导航栏，搜索框，按钮组

这一期，回到支付系统的核心业务，即支付。每个电商公司的支付系统都已经或多或少的实现了交易核心功能，可也都是一直在改进，总是不断的有新的需求冒出来。所以这一期开始，我们梳理一下：到底有哪些支付方式？每种支付方式都是怎么运作的？ 支付和交易 说到支付就不得不提交易。这两个概念在不同公司中是不一样的。我们的定义是，交易是生成订单；支付是对订单进行付款。 订单生成过程我们以后另开话题来说。这一次重点介绍支付。而就支付行为来说，我们碰到的大部分都是单次支付，其次还有转账和退款。在苹果推出订阅支付后，国内支付宝等也在陆续跟进。 单次支付是我们用的最多的支付方式了，即一次结清所有款项。把单次支付走通了，其他支付方式也容易处理。 本期重点介绍单次支付。 银行卡支付 先说大家比较熟悉的银行卡支付，它分为线上支付和线下支付两种形式。线下支付就是通常说的POS收单，这里不介绍这个内容。对线上支付，按照卡的类别，分为贷记卡支付，也叫motopay、ePOS，即信用卡支付；和借记卡支付。按照支付形态，又分为认证支付、网银支付、快捷支付几种形态。银行卡网银支付要求银行卡必须开通在线支付功能，而快捷支付并不需要开通在线支付功能。主要利用支付验证要素（卡号、密码、手机号、CVN2、CVV2等），结合安全认证（例如短信验证码），让持卡人完成互联网支付。 认证支付 指用户在绑卡时，将卡信息提供给电商。这样在支付时

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> SOLID 原则： S 单一职责原则 单一责任，一个类只负责一个职责。(single responsiblity) O 开闭原则 对继承和发展开放，对修改关闭。(open and close) L 里式替换原则 子类可是替换父类 （Liskov substituation principle） L 迪米特法则 尽可能的少知道其他类，目的在于降低耦合，减少类之间的依赖关系 (Low of demeter) i 接口隔离原则，实现最小接口，使接口类不包括多余的方法，子类不用实现用不上的方法 (interface ) D 依赖倒置原则 (dependency reverse) 至于以上六个原则如何在实际中应用，后面我也将详细讲解。下面将会继续学习23种设计模式。 设计模式总共分为三个大类：创建型，结构型，行为型。 1.创建型： 5种，工厂方法，抽象工厂，单例，建造者，原型 2.结构型：7种，适配器，装饰器，代理，外观，桥接，组合，享元 3.行为型：11种，策略，模板方法，观察者，责任链，命令，备忘录，状态，访问者，中介者，解释器 来源： oschina 链接： https://my.oschina.net/u/2274056/blog/3155473