青橙电商有关的一些知识点

Dubbo（开源分布式服务框架）

Dubbo(读音[ˈdʌbəʊ])是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。

Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

通用mapper

通用 Mapper 是一个可以实现任意 MyBatis 通用方法的框架，项目提供了常规的增删改查操作以及Example相关的单表操作。为什么要用通用mapper？我们这里列举一下原生Mybatis的痛点：

1、mapper.xml文件里有大量的sql，当数据库表字段变动，配置文件就要修改

2、需要自己实现sql分页，select * from table where . . . limit 1,3
自己手写分页，除了传参page、pageSize，还需要返回条目总数count。

3、数据库可移植性差：如果项目更换数据库，比如oracle-->mysql，mapper.xml中的sql要重新写，因为Oracle的PLSQL 和mysql 支持的函数是不同的。

4、生成的代码量过大。

5、批量操作，批量插入，批量更新，需要自写。

而这些，通过通用mapper就可以很轻松的解决了。

分布式ID生成解决方案

在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。如在美团点评的金融、支付、餐饮、酒店、猫眼电影等产品的系统中，数据日渐增长，对数据分库分表后需要有一个唯一ID来标识一条数据或消息，数据库的自增ID显然不能满足需求；特别一点的如订单、骑手、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。

UUID

常见的方式。可以利用数据库也可以利用程序生成，一般来说全球唯一。

优点：

1）简单，代码方便。
2）生成ID性能非常好，基本不会有性能问题。
3）全球唯一，在遇见数据迁移，系统数据合并，或者数据库变更等情况下，可以从容应对。

缺点：

1）没有排序，无法保证趋势递增。
2）UUID往往是使用字符串存储，查询的效率比较低。
3）存储空间比较大，如果是海量数据库，就需要考虑存储量的问题。
4）传输数据量大
5） 不可读。

Redis生成ID

当使用数据库来生成ID性能不够要求的时候，我们可以尝试使用Redis来生成ID。这主要依赖于Redis是单线程的，所以也可以用来生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY来实现。

优点：

1）不依赖于数据库，灵活方便，且性能优于数据库。
2）数字ID天然排序，对分页或者需要排序的结果很有帮助。

缺点：

1）如果系统中没有Redis，还需要引入新的组件，增加系统复杂度。
2）需要编码和配置的工作量比较大。
3）网络传输造成性能下降。

开源算法snowflake

snowflake是Twitter开源的分布式ID生成算法，结果是一个long型的ID。其核心思想是：使用41bit作为毫秒数，10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID），12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID），最后还有一个符号位，永远是0

定时任务解决方案-SpringTask（超时订单自动关闭）

​Spring3.0以后自主开发的定时任务工具，spring-task，可以将它比作一个轻量级的Quartz，而且使用起来很简单，除spring相关的包外不需要额外的包，而且支持注解和配置文件两种形式。

Cron表达式

Cron表达式是一个字符串，字符串以5或6个空格隔开，分开6或7个域，每一个域代表一个含义,Cron有如下两种语法
格式：
Seconds Minutes Hours DayofMonth Month DayofWeek Year 或
Seconds Minutes Hours DayofMonth Month DayofWeek

注意：SpringTask不支持第一种格式，也就是说只能写6个域！

每一个域可出现的字符如下：

Seconds:可出现,- * / 四个字符，有效范围为0-59的整数
Minutes:可出现,- * / 四个字符，有效范围为0-59的整数
Hours:可出现,- * / 四个字符，有效范围为0-23的整数
DayofMonth:可出现,- * / ? L W C八个字符，有效范围为1-31的整数
Month:可出现,- * / 四个字符，有效范围为1-12的整数或JAN-DEC
DayofWeek:可出现,- * / ? L C #四个字符，有效范围为1-7的整数或SUN-SAT两个范围。 1表示星期天，2表示星期一， 依次类推
Year:可出现,- * / 四个字符，有效范围为1970-2099年
每一个域都使用数字，但还可以出现如下特殊字符，它们的含义是：

(1)*：表示匹配该域的任意值，假如在Minutes域使用,即表示每分钟都会触发事件。
(2)?：只能用在DayofMonth和DayofWeek两个域。它也匹配域的任意值，但实际不会。因为DayofMonth和DayofWeek会相互影响。
例如想在每月的20日触发调度，不管20日到底是星期几，则只能使用如下写法： 13 13 15 20 * ?,其中最后一位只能用？，而不能使用，如果使用*表示不管星期几都会触发，实际上并不是这样。
(3)-：表示范围，例如在Minutes域使用5-20，表示从5分到20分钟每分钟触发一次
(4)/：表示起始时间开始触发，然后每隔固定时间触发一次，例如在Minutes域使用5/20,则意味着5分钟触发一次，而25，45等分别触发一次.
(5),：表示列出枚举值值。例如：在Minutes域使用5,20，则意味着在5和20分每分钟触发一次。

BCrypt简介

在用户模块，对于用户密码的保护，通常都会进行加密。我们通常对密码进行加密，然后存放在数据库中，在用户进行登录的时候，将其输入的密码进行加密然后与数据库中存放的密文进行比较，以验证用户密码是否正确。 目前，MD5和BCrypt比较流行。相对来说，BCrypt比MD5更安全。

Spring Security简介

安全框架概述

​什么是安全框架？ 解决系统安全问题的框架。如果没有安全框架，我们需要手动处理每个资源的访问控制，非常麻烦。使用安全框架，我们可以通过配置的方式实现对资源的访问限制。

常用安全框架

​Spring Security：spring家族一员。是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。它提供了一组可以在Spring应用上下文中配置的Bean，充分利用了Spring IoC，DI（控制反转Inversion of Control, DI:Dependency Injection 依赖注入）和AOP（面向切面编程）功能，为应用系统提供声明式的安全访问控制功能，减少了为企业系统安全控制编写大量重复代码的工作。

​Apache Shiro 是一个功能强大且易于使用的Java安全框架,提供了认证,授权,加密,和会话管理。

认证与授权

认证：限制用户只能登陆才可以访问资源。
授权：限制用户必须有某资源的访问权限才可以访问。

什么是RBAC

​权限系统提的最多的就是 RBAC（Role-Based Access Control 基于角色的访问控制）。 所谓角色，其实就是权限的集合，某个角色就是某几个权限的结合。其目的是为了简化授权和鉴权的过程。

​首选说一下为什么要进行访问控制。为了屏蔽无关人员操作系统的某个功能，防止误操作产生的垃圾数据或数据丢失。

小公司和比较简单的权限系统使用的基于用户的访问控制如下:

这种访问控制只适用于操作人员比较少的系统，如果操作人员较多，对每个操作人员都进行授权操作，无疑是非常繁琐的。

所以我们就需要基于角色的访问控制

thymeleaf简介

Thymeleaf是一个适用于Web和独立环境的现代服务器端Java模板引擎。

Thymeleaf的主要目标是为您的开发工作流程带来优雅的自然模板 - 可以在浏览器中正确显示的HTML，也可以用作静态原型，从而在开发团队中实现更强大的协作。

通过Spring Framework模块，与您喜欢的工具的大量集成，以及插入您自己的功能的能力，Thymeleaf是现代HTML5 JVM Web开发的理想选择 - 尽管它可以做得更多。

为什么要使用thymeleaf

thymeleaf PK Vue.js

​我们在前期课程中已经讲解了vue.js这样的前端框架，为什么我们还要在项目中使用thymeleaf ? 首先说这两种技术本质上属于不同类型的产品。vue.js属于前端框架，而thymeleaf 属于模板引擎。虽然它们可以实现相同的功能（比如一个列表），但是它们的工作过程却是不同： vue.js通过异步方式请求数据，后端给前端返回json，前端通过vue指令循环渲染列表。thymeleaf 则是在后端实现页面的渲染，将渲染后的页面直接给浏览器展示。

​那什么时候使用vue.js，什么使用thymeleaf 呢？一般来说，管理后台我们会使用前端框架，而网站前台有些页面会使用thymeleaf。原因有两点：

（1）因为使用vue.js由于是异步请求，从页面打开到信息的展示会出现延迟，而使用thymeleaf，页面打开会立刻看到页面的信息。
（2）异步加载的数据不会被搜索引擎抓取。所以当我们希望数据被搜索引擎收录，就需要使用thymeleaf这样的模板引擎。

thymeleaf PK JSP

有同学会问，thymeleaf 目前所做的工作和jsp有相似之处。没错，thymeleaf和jsp都是属于服务端渲染技术。thymeleaf比jsp功能强大许多，它的强大已经超出你的想象。我们在此项目后会学习一个新的框架叫spring boot ，thymeleaf就是spring boot 官方推荐使用的模板引擎。

首页广告轮播图渲染、首页分类导航渲染

商品详细页静态渲染

商品详细页通过thymeleaf静态渲染为html页面。

为什么要静态渲染为html页面而不是动态渲染呢？

（1）避免在每次打开商品详细页都查询数据库，可以极大减轻数据的访问压力。

（2）可以把生成的html放入nginx运行。nginx可以高达五万并发，极大提升网站的访问速度，解决电商网站高并发的问题 。

我们是将每一个spu生成一个页面，还是将每个sku生成一个页面呢？京东的做法是每个sku一个页面，点击规格后跳转页面。我们青橙的实现方式与京东相同。

SpringDataRedis简介

SpringDataRedis属于Spring Data家族一员，用于对redis的操作进行封装的框架

Spring Data -----  Spring的一个子项目。Spring官方提供一套数据层综合解决方案，用于简化数据库访问，支持NoSQL和关系数据库存储。包括Spring Data JPA、Spring Data Redis、SpringDataSolr、SpringDataElasticsearch、Spring DataMongodb等框架。

Redis不仅仅支持简单的k/v类型的数据，同时还提供list，hash，set，zset等数据结构的存储

缓存穿透、缓存击穿、缓存雪崩

缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。
解决方案：
1.接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
2.从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-0。这样可以防止攻击用户反复用同一个id暴力攻击。
3.使用缓存预热
缓存预热就是将数据提前加入到缓存中，当数据发生变更，再将最新的数据更新到缓存。
后边我们就用缓存预热的方式实现对分类导航、广告轮播图等数据的缓存。

缓存击穿是指缓存中没有但数据库中有的数据。这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。
解决方案：
1.设置热点数据永远不过期。
2.缓存预热

​缓存雪崩是指缓存数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
解决方案：
1.缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
2.设置热点数据永远不过期。
3.使用缓存预热

商品分类导航缓存

需求分析
为了提升首页的加载速度，减轻数据库访问压力，我们将首页的商品分类导航数据加载在缓存中。

实现思路
为了避免缓存穿透、击穿等问题，我们采用缓存预热的方式实现对分类导航数据的缓存。
考虑到商品分类导航数据不经常变动，所以我们不设置过期时间。

广告轮播图缓存

需求分析
为了提升首页的加载速度，减轻数据库访问压力，我们将首页的广告轮播图数据加载在缓存中。

实现思路
使用“缓存预热”的方式实现
广告数据不只是轮播图，我们可以使用hash来存储广告数据。

商品详细页价格缓存

需求分析
我们已经将商品的信息生成为静态页面，但是商品价格经常变动，如果每次价格变动后都对静态页重新生成会影响服务器性能。所以，对于商品价格，我们采用异步调用的方式来进行客户端渲染。

实现思路
（1）商品服务启动后加载全部价格数据到缓存。使用hash存储，skuID作为小KEY

（2）从缓存中查询商品价格，封装为controller，并设置可跨域调用

什么叫跨域？

​JavaScript出于安全方面的考虑，不允许跨域调用其他页面的对象。那什么是跨域呢，简单地理解就是因为JavaScript同源策略的限制，a.com域名下的js无法操作b.com或是c.a.com域名下的对象。

当协议、子域名、主域名、端口号中任意一个不相同时，都算作不同域。不同域之间相互请求资源，就算作“跨域”。
​
现在我们要实现的查询商品价格缓存功能就存在跨域问题。后端controller在http://www.qingcheng.com，商品详细页在http://item.qingcheng.com

如何解决跨域问题？我们使用CORS实现跨域。

​CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）。它允许浏览器向跨源服务器，发出 XMLHttpRequest 请求，从而克服了AJAX只能同源使用的限制。使用非常简单，只需要在controller类上添加一个 @CrossOrigin注解即可

（3）修改商品详细页模板，使用ajax读取价格，并进行客户端渲染。

走进ElasticSearch

全文检索

为什么要使用全文检索

用户访问我们的首页，一般都会直接搜索来寻找自己想要购买的商品。
而商品的数量非常多，而且分类繁杂。如果能正确的显示出用户想要的商品，并进行合理的过滤，尽快促成交易，是搜索系统要研究的核心。
面对这样复杂的搜索业务和数据量，使用传统数据库搜索就显得力不从心，一般我们都会使用全文检索技术。
常见的全文检索技术有 Lucene、solr、elasticsearch等。

理解索引结构

下图是索引结构，下边黑色部分是物理结构，上边黄色部分是逻辑结构，逻辑结构也是为了更好的去描述工作原理及去使用物理结构中的索引文件。

逻辑结构部分是一个倒排索引表：
1、将要搜索的文档内容分词，所有不重复的词组成分词列表。 2、将搜索的文档最终以Document方式存储起来。
3、每个词和docment都有关联。
如下：

现在，如果我们想搜索 quick brown，我们只需要查找包含每个词条的文档：

两个文档都匹配，但是第一个文档比第二个匹配度更高。如果我们使用仅计算匹配词条数量的简单 相似性算法 ，那么，我们可以说，对于我们查询的相关性来讲，第一个文档比第二个文档更佳。

Elasticsearch简介

​ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
​我们建立一个网站或应用程序，并要添加搜索功能，但是想要完成搜索工作的创建是非常困难的。我们希望搜索解决方案要运行速度快，我们希望能有一个零配置和一个完全免费的搜索模式，我们希望能够简单地使用JSON通过HTTP来索引数据，我们希望我们的搜索服务器始终可用，我们希望能够从一台开始并扩展到数百台，我们要实时搜索，我们要简单的多租户，我们希望建立一个云的解决方案。因此我们利用Elasticsearch来解决所有这些问题及可能出现的更多其它问题。

优点：
（1） 可以作为一个大型分布式集群（数百台服务器）技术，处理PB级数据，服务大公司；也可以运行在单机上
（2） 将全文检索、数据分析以及分布式技术，合并在了一起，才形成了独一无二的ES；
（3） 开箱即用的，部署简单
（4） 全文检索，同义词处理，相关度排名，复杂数据分析，海量数据的近实时处理

下表是Elasticsearch与MySQL数据库逻辑结构概念的对比

Elasticsearch	关系型数据库Mysql
索引(index)	数据库(databases)
类型(type)	表(table)
文档(document)	行(row)

走进RabbitMQ

消息中间件简介
​消息中间件（消息队列）是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题实现高性能，高可用，可伸缩和最终一致性[架构] 使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ
以下介绍消息队列在实际应用中常用的使用场景：异步处理，应用解耦，流量削锋和消息通讯四个场景

什么是RabbitMQ
RabbitMQ 是一个由 Erlang 语言开发的 AMQP 的开源实现。
AMQP ：Advanced Message Queue，高级消息队列协议。它是应用层协议的一个开放标准，为面向消息的中间件设计，基于此协议的客户端与消息中间件可传递消息，并不受产品、开发语言等条件的限制。
RabbitMQ 最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。具体特点包括：
1.可靠性（Reliability）
RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认、发布确认。
2.灵活的路由（Flexible Routing）
在消息进入队列之前，通过 Exchange 来路由消息的。对于典型的路由功能，RabbitMQ 已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能，可以将多个 Exchange 绑定在一起，也通过插件机制实现自己的 Exchange 。
3.消息集群（Clustering）
多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker 。
4.高可用（Highly Available Queues）
队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用。
5.多种协议（Multi-protocol）
RabbitMQ 支持多种消息队列协议，比如 STOMP、MQTT 等等。
6.多语言客户端（Many Clients）
RabbitMQ 几乎支持所有常用语言，比如 Java、.NET、Ruby 等等。
7.管理界面（Management UI）
RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker 的许多方面。
8.跟踪机制（Tracing）
如果消息异常，RabbitMQ 提供了消息跟踪机制，使用者可以找出发生了什么。
9.插件机制（Plugin System）
RabbitMQ 提供了许多插件，来从多方面进行扩展，也可以编写自己的插件。

架构图与主要概念

RabbitMQ Server： 也叫broker server，它是一种传输服务。 他的角色就是维护一条从Producer到Consumer的路线，保证数据能够按照指定的方式进行传输。
Producer： 消息生产者，如图A、B、C，数据的发送方。消息生产者连接RabbitMQ服务器然后将消息投递到Exchange。
Consumer：消息消费者，如图1、2、3，数据的接收方。消息消费者订阅队列， RabbitMQ将Queue中的消息发送到消息消费者。
Exchange：生产者将消息发送到Exchange（交换器），由Exchange将消息路由到一个或多个Queue中（或者丢弃）。Exchange并不存储消息。RabbitMQ中的Exchange有direct、fanout、topic、headers四种类型，每种类型对应不同的路由规则。
Queue：（队列）是RabbitMQ的内部对象，用于存储消息。消息消费者就是通过订阅队列来获取消息的，RabbitMQ中的消息都只能存储在Queue中，生产者生产消息并最终投递到Queue中，消费者可以从Queue中获取消息并消费。多个消费者可以订阅同一个Queue，这时Queue中的消息会被平均分摊给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理。
RoutingKey：生产者在将消息发送给Exchange的时候，一般会指定一个routing key，来指定这个消息的路由规则，而这个routing key需要与Exchange Type及binding key联合使用才能最终生效。在Exchange Type与binding key固定的情况下（在正常使用时一般这些内容都是固定配置好的），我们的生产者就可以在发送消息给Exchange时，通过指定routing key来决定消息流向哪里。RabbitMQ为routing key设定的长度限制为255 bytes。
Connection： （连接）：Producer和Consumer都是通过TCP连接到RabbitMQ Server的。以后我们可以看到，程序的起始处就是建立这个TCP连接。
Channels： （信道）：它建立在上述的TCP连接中。数据流动都是在Channel中进行的。也就是说，一般情况是程序起始建立TCP连接，第二步就是建立这个Channel。
VirtualHost：权限控制的基本单位，一个VirtualHost里面有若干Exchange和MessageQueue，以及指定被哪些user使用

RabbitMQ发送与接收消息

什么是Direct模式
我们需要将消息发给唯一一个节点时使用这种模式，这是最简单的一种形式。

任何发送到Direct Exchange的消息都会被转发到RouteKey中指定的Queue。
1.一般情况可以使用rabbitMQ自带的Exchange：”"(该Exchange的名字为空字符串，下文称其为default Exchange)。
2.这种模式下可以不需要将Exchange进行任何绑定(binding)操作
3.消息传递时需要一个“RouteKey”，可以简单的理解为要发送到的队列名字。
4.如果vhost中不存在RouteKey中指定的队列名，则该消息会被抛弃。

什么是分列（Fanout）模式
当我们需要将消息一次发给多个队列时，需要使用这种模式。如下图：

任何发送到Fanout Exchange的消息都会被转发到与该Exchange绑定(Binding)的所有Queue上。
1.这种模式需要提前将Exchange与Queue进行绑定，一个Exchange可以绑定多个Queue，一个Queue可以同多个Exchange进行绑定。
2.这种模式不需要RouteKey
3.如果接受到消息的Exchange没有与任何Queue绑定，则消息会被抛弃。

开源单点登录系统CAS

什么是单点登录

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
​我们目前的系统存在诸多子系统，而这些子系统是分别部署在不同的服务器中，那么使用传统方式的session是无法解决的，我们需要使用相关的单点登录技术来解决。

当我们访问其中一个前台系统需要登录才可以访问的页面时，自动跳转到登录中心进行登录，登录后再次跳转回该前台系统，该前台系统可以获取登录名。
实现单点登录有多种方案：
（1）使用redis实现session共享
（2）使用开源的单点登录系统（推荐）

CAS简介
​CAS（Central Authentication Service的缩写，中央认证服务）是
CAS 具有以下特点：
【1】开源的企业级单点登录解决方案。
【2】CAS Server 为需要独立部署的 Web 应用
【3】CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括 Java, .Net, PHP, Perl,Apache, uPortal, Ruby 等。

从结构上看，CAS 包含两个部分： CAS Server 和 CAS Client。
CAS Server 需要独立部署，主要负责对用户的认证工作；
CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。
下图是 CAS 最基本的协议过程：

SSO单点登录访问流程主要有以下步骤：
1.访问服务：SSO客户端发送请求访问应用系统提供的服务资源。
2.定向认证：SSO客户端会重定向用户请求到SSO服务器。
3.用户认证：用户身份认证。
4.发放票据：SSO服务器会产生一个随机的ServiceTicket。
5.验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端访问服务。
6.传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。

分布式事务解决方案

​刚才我们编写的扣减库存与保存订单是在两个服务中存在的，如果扣减库存后订单保存失败了是不会回滚的，这样就会造成数据不一致的情况，这其实就是我们所说的分布式事务的问题，接下来我们来学习分布式事务的解决方案。

本地事务与分布式事务

事务
数据库事务(简称：事务，Transaction)是指数据库执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。
事务拥有以下四个特性，习惯上被称为ACID特性：
原子性(Atomicity)：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
一致性(Consistency)：事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态是指数据库中的数据应满足完整性约束。除此之外，一致性还有另外一层语义，就是事务的中间状态不能被观察到(这层语义也有说应该属于原子性)。
隔离性(Isolation)：多个事务并发执行时，一个事务的执行不应影响其他事务的执行，如同只有这一个操作在被数据库所执行一样。
持久性(Durability)：已被提交的事务对数据库的修改应该永久保存在数据库中。在事务结束时，此操作将不可逆转。

本地事务
起初，事务仅限于对单一数据库资源的访问控制,架构服务化以后，事务的概念延伸到了服务中。倘若将一个单一的服务操作作为一个事务，那么整个服务操作只能涉及一个单一的数据库资源,这类基于单个服务单一数据库资源访问的事务，被称为本地事务(Local Transaction)。

分布式事务
分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上,且属于不同的应用，分布式事务需要保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
最早的分布式事务应用架构很简单，不涉及服务间的访问调用，仅仅是服务内操作涉及到对多个数据库资源的访问。

​当一个服务操作访问不同的数据库资源，又希望对它们的访问具有事务特性时，就需要采用分布式事务来协调所有的事务参与者。
​对于上面介绍的分布式事务应用架构，尽管一个服务操作会访问多个数据库资源，但是毕竟整个事务还是控制在单一服务的内部。如果一个服务操作需要调用另外一个服务，这时的事务就需要跨越多个服务了。在这种情况下，起始于某个服务的事务在调用另外一个服务的时候，需要以某种机制流转到另外一个服务，从而使被调用的服务访问的资源也自动加入到该事务当中来。下图反映了这样一个跨越多个服务的分布式事务：

如果将上面这两种场景(一个服务可以调用多个数据库资源，也可以调用其他服务)结合在一起，对此进行延伸，整个分布式事务的参与者将会组成如下图所示的树形拓扑结构。在一个跨服务的分布式事务中，事务的发起者和提交均系同一个，它可以是整个调用的客户端，也可以是客户端最先调用的那个服务。

较之基于单一数据库资源访问的本地事务，分布式事务的应用架构更为复杂。在不同的分布式应用架构下，实现一个分布式事务要考虑的问题并不完全一样，比如对多资源的协调、事务的跨服务传播等，实现机制也是复杂多变。

分布式事务相关理论

CAP定理

CAP定理是在 1998年加州大学的计算机科学家 Eric Brewer （埃里克.布鲁尔）提出，分布式系统有三个指标

• Consistency 一致性
• Availability 可用性
• Partition tolerance 分区容错

它们的第一个字母分别是 C、A、P。Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。
分区容错 Partition tolerance
大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。
Availability 中文叫做"可用性"，意思是只要收到用户的请求，服务器就必须给出回应。
Consistency 中文叫做"一致性"。意思是，写操作之后的读操作，必须返回该值。
系统设计时只能选择一个目标。如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。

BASE理论

BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：

既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

Basically Available(基本可用)
什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：

1. 响应时间上的损失：正常情况下的搜索引擎 0.5 秒即返回给用户结果，而基本可用的搜索引擎可以在 1 秒作用返回结果。
2. 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单，但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

Soft state（软状态）
什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。
软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
Eventually consistent（最终一致性）
系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值。

分布式事务解决方案

基于XA协议的两阶段提交
首先我们来简要看下分布式事务处理的XA规范 ：

可知XA规范中分布式事务有AP，RM，TM组成：
其中应用程序(Application Program ，简称AP)：AP定义事务边界（定义事务开始和结束）并访问事务边界内的资源。
资源管理器(Resource Manager，简称RM)：Rm管理计算机共享的资源，许多软件都可以去访问这些资源，资源包含比如数据库、文件系统、打印机服务器等。
事务管理器(Transaction Manager ，简称TM)：负责管理全局事务，分配事务唯一标识，监控事务的执行进度，并负责事务的提交、回滚、失败恢复等。
二阶段协议:
第一阶段TM要求所有的RM准备提交对应的事务分支，询问RM是否有能力保证成功的提交事务分支，RM根据自己的情况，如果判断自己进行的工作可以被提交，那就就对工作内容进行持久化，并给TM回执OK；否者给TM的回执NO。RM在发送了否定答复并回滚了已经的工作后，就可以丢弃这个事务分支信息了。
第二阶段TM根据阶段1各个RM prepare的结果，决定是提交还是回滚事务。如果所有的RM都prepare成功，那么TM通知所有的RM进行提交；如果有RM prepare回执NO的话，则TM通知所有RM回滚自己的事务分支。
也就是TM与RM之间是通过两阶段提交协议进行交互的.
优点： 尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）
缺点： 实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。

TCC补偿机制
TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：
Try 阶段主要是对业务系统做检测及资源预留
Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。 Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

例如： A要向 B 转账，思路大概是：

我们有一个本地方法，里面依次调用
1、首先在 Try 阶段，要先调用远程接口把 B和 A的钱给冻结起来。
2、在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。
3、如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法 (Cancel)。

优点： 相比两阶段提交，可用性比较强
缺点： 数据的一致性要差一些。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。

消息最终一致性
消息最终一致性应该是业界使用最多的，其核心思想是将分布式事务拆分成本地事务进行处理，这种思路是来源于ebay。我们可以从下面的流程图中看出其中的一些细节：

基本思路就是：
消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。
消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。
生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。
优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。
缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

库存扣减分布式事务的实现

需求分析
如果订单在创建时发生了异常，此时库存已经扣减了，这样库存就比实际中的数量要少，造成数据不一致，为了避免这种情况，我们需要采用消息最终一致性的分布式事务解决方案。

实现思路
如下图：
（1） 当订单服务发生异常时，发送消息给mq ，消息内容为要购物车数据，用于恢复库存
（2） 商品服务从mq提取消息，保存到库存回滚表中
（3） 在管理后台开启定时任务，定时扫描库存回滚表执行库存回滚。

为什么要设置成联合主键的形式呢？ 因为消息在发送时，可能会因为失败而重复发送，而重复发送可能造成回滚数据的重复。订单编号+sku编号组合起来如果相同一定是同一笔数据 ，所以我们将其设置成联合主键，这样在插入重复数据时就会因为主键唯一冲突而无法插入。

微信支付入门

微信支付接口调用的整体思路：
按API要求组装参数，以XML方式发送（POST）给微信支付接口（URL）,微信支付接口也是以XML方式给予响应。程序根据返回的结果（其中包括支付URL）生成二维码或判断订单状态。
我们解压从官网下载的sdk ,安装到本地仓库

二维码JS插件- QRcode.js
QRCode.js 是一个用于生成二维码的 JavaScript 库。主要是通过获取 DOM 的标签,再通过 HTML5 Canvas 绘制而成,不依赖任何库。支持该库的浏览器有：IE6~10, Chrome, Firefox, Safari, Opera, Mobile Safari, Android, Windows Mobile, 等

内网映射工具EchoSite
在请求统一下单接口时，有个参数notify_url ，这个是回调地址，也就是在支付成功后微信支付会自动访问这个地址，通知业务系统支付完成。但这个地址必须是互联网可以访问的（也就是有域名的）。
那么如何测试呢？我们可以借助一个工具 EchoSite 内网映射工具

微信支付二维码
前端页面向后端传递订单号，后端根据订单号查询订单，检查是否为当前用户的未支付订单，如果是则根据订单号和金额生成支付url返给前端，前端得到支付url生成支付二维码。

推送支付通知

当用户完成扫码支付后，跳转到支付成功页面

服务端推送方案

我们需要将支付的结果通知前端页面，其实就是我们通过所说的服务器端推送，主要有三种实现方案

（1）Ajax 短轮询
Ajax 轮询主要通过页面端的 JS 定时异步刷新任务来实现数据的加载
如果我们使用ajax短轮询方式，需要后端提供方法，通过调用微信支付接口实现根据订单号查询支付状态的方法（参见查询订单API） 。 前端每间隔三秒查询一次，如果后端返回支付成功则执行页面跳转。
缺点：这种方式实时效果较差，而且对服务端的压力也较大。

（2）长轮询
长轮询主要也是通过 Ajax 机制，但区别于传统的 Ajax 应用，长轮询的服务器端会在没有数据时阻塞请求直到有新的数据产生或者请求超时才返回，之后客户端再重新建立连接获取数据。
如果使用长轮询，也同样需要后端提供方法，通过调用微信支付接口实现根据订单号查询支付状态的方法，只不过循环是写在后端的。
缺点：长轮询服务端会长时间地占用资源，如果消息频繁发送的话会给服务端带来较大的压力。

（3）WebSocket 双向通信
WebSocket 是 HTML5 中一种新的通信协议，能够实现浏览器与服务器之间全双工通信。如果浏览器和服务端都支持 WebSocket 协议的话，该方式实现的消息推送无疑是最高效、简洁的。并且最新版本的 IE、Firefox、Chrome 等浏览器都已经支持 WebSocket协议，Apache Tomcat 7.0.27 以后的版本也开始支持 WebSocket。

超时未支付订单处理

需求分析
超过60分钟未支付的订单，我们需要进行超时订单的处理：先调用微信支付api，查询该订单的支付状态。如果未支付调用关闭订单的api，并修改订单状态为已关闭，并回滚库存数。如果该订单已经支付，做补偿操作（修改订单状态和记录）。

实现思路
如何获取超过60分钟的订单？我们目前有两种实现方案
（1）定时任务轮询方案
编写定时任务，查询所有60分钟前创建的订单列表。
循环此订单列表，查询每个订单的支付状态。如果已支付进行状态补偿，如果未支付则关闭订单。
这种实现方案缺点是时间精度不高，对系统压力比较大。
（2）使用延迟消息队列
所谓延迟消息队列，就是消息的生产者发送的消息并不会立刻被消费，而是在设定的时间之后才可以消费。
我们可以在订单创建时发送一个延迟消息，消息为订单号，青橙系统会在60分钟后取出这个消息，然后查询订单的支付状态，根据结果做出相应的处理。
我们在青橙中采用延迟消息队列的实现方案。
另外我们还会用到微信支付api中的查询订单和关闭订单。

rabbitmq延迟消息

使用RabbitMQ来实现延迟消息必须先了解RabbitMQ的两个概念：消息的TTL和死信Exchange，通过这两者的组合来实现上述需求。

消息的TTL（Time To Live）
消息的TTL就是消息的存活时间。RabbitMQ可以对队列和消息分别设置TTL。对队列设置就是队列没有消费者连着的保留时间，也可以对每一个单独的消息做单独的设置。超过了这个时间，我们认为这个消息就死了，称之为死信。
我们创建一个队列queue.temp，在Arguments 中添加x-message-ttl 为5000 （单位是毫秒），那所在压在这个队列的消息在5秒后会消失。

死信交换器 Dead Letter Exchanges
一个消息在满足如下条件下，会进死信路由，记住这里是路由而不是队列，一个路由可以对应很多队列。
（1）一个消息被Consumer拒收了，并且reject方法的参数里requeue是false。也就是说不会被再次放在队列里，被其他消费者使用。
（2）上面的消息的TTL到了，消息过期了。
（3）队列的长度限制满了。排在前面的消息会被丢弃或者扔到死信路由上。
Dead Letter Exchange其实就是一种普通的exchange，和创建其他exchange没有两样。只是在某一个设置Dead Letter Exchange的队列中有消息过期了，会自动触发消息的转发，发送到Dead Letter Exchange中去。

秒杀

秒杀技术实现核心思想是运用缓存减少数据库瞬间的访问压力！读取商品详细信息时运用缓存，当用户点击抢购时减少缓存中的库存数量，当库存数为0时或活动期结束时，同步到数据库。 产生的秒杀预订单也不会立刻写到数据库中，而是先写到缓存，当用户付款成功后再写入数据库。

多线程下单

在审视秒杀中，操作一般都是比较复杂的，而且并发量特别高，比如，检查当前账号操作是否已经秒杀过该商品，检查该账号是否存在存在刷单行为，记录用户操作日志等。
下订单这里，我们一般采用多线程下单，但多线程中我们又需要保证用户抢单的公平性，也就是先抢先下单。我们可以这样实现，用户进入秒杀抢单，如果用户复合抢单资格，只需要记录用户抢单数据，存入队列，多线程从队列中进行消费即可，存入队列采用左压，多线程下单采用右取的方式。

Spring实现多线程
我们过去实现多线程的方式通常是继承Thread类或者实现Runnable 接口，这种方式实现起来比较麻烦。spring封装了Java的多线程的实现，你只需要关注于并发事物的流程以及一些并发负载量等特性。spring通过任务执行器TaskExecutor来实现多线程与并发编程。通常使用ThreadPoolTaskExecutor来实现一个基于线程池的TaskExecutor.

多线程抢单

用户每次下单的时候，我们都让他们先进行排队，然后采用多线程的方式创建订单，排队我们可以采用Redis的队列
实现，多线程下单我们可以采用Spring的异步实现。

并发超卖问题解决

超卖问题，这里是指多人抢购同一商品的时候，多人同时判断是否有库存，如果只剩一个，则都会判断有库存，此时
会导致超卖现象产生，也就是一个商品下了多个订单的现象。

解决超卖问题，可以利用Redis队列实现，给每件商品创建一个独立的商品个数队列，例如：A商品有2个，A商品的ID为1001，则可以创建一个队列,key=SeckillGoodsCountList_1001,往该队列中塞2次该商品ID。
每次给用户下单的时候，先从队列中取数据，如果能取到数据，则表明有库存，如果取不到，则表明没有库存，这样就可以防止超卖问题产生了。
在我们队Redis进行操作的时候，很多时候，都是先将数据查询出来，在内存中修改，然后存入到Redis，在并发场景，会出现数据错乱问题，为了控制数量准确，我们单独将商品数量整一个自增键，自增键是线程安全的，所以不担心并发场景的问题。

超时订单库存回滚

用户每次下单后，不一定会立即支付，甚至有可能不支付，那么此时我们需要删除用户下的订单，并回滚库存。这里我们可以采用MQ的延时消息实现，每次用户下单的时候，如果订单创建成功，则立即发送一个延时消息到MQ中，等待消息被消费的时候，先检查对应订单是否下单支付成功，如果支付成功，会在MySQL中生成一个订单，如果MySQL中没有支付，则Redis中还有该订单信息的存在，需要删除该订单信息以及用户排队信息，并恢复库存。