microservice/problem.md · 万孝国/java_study

### 单点登录
+ 单点登录（Single Sign On）是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。一般用于分布式项目中
![SSO单点登录流程](img/SSO单点登录.jpg)

### 购物车的实现
+ 购物车跟用户的关系
  + 一个用户必须对应一个购物车【一个用户不管买多少商品，都会存在属于自己的购物车中。】
  + 单点登录一定在购物车之前。
+ 跟购物车有关的操作有哪些
  + （a）添加购物车
    + 用户未登录状态　
      + 添加到什么地方?未登录将数据保存到什么地方?
      + Redis? --- 京东 Cookie? --- 自己开发项目的时候【如果浏览器禁用cookie】
    + 用户登录状态
      + Redis 缓存中 【读写速度快】
　　　　　　　　Hash ：hset(key,field,value)
　　　　　　　　Key:user:userId:cart
　　　　　　　　Hset(key,skuId,value);
　　　+ 存在数据库中【oracle，mysql】
  + (b) 展示购物车
    + 未登录状态展示: 直接从cookie 中取得数据展示即可
    + 登录状态: 
      + 用户一旦登录：必须显示数据库【redis】+cookie 中的购物车的数据
      + Cookie 中有三条记录, Redis中有五条记录　真正展示的时候应该是八条记录

### 消息队列在项目中的应用
+ 背景：在分布式系统中是如何处理高并发的。
+ 由于在高并发的环境下，来不及同步处理用户发送的请求，则会导致请求发生阻塞。
+ 比如说，大量的insert，update之类的请求同时到达数据库MYSQL，直接导致无数的行锁表锁，甚至会导致请求堆积很多。从而触发 too many connections 错误。
+ 使用消息队列可以解决【异步通信】
+ 消息队列的弊端：消息的不确定性，延迟队列，轮询技术来解决
+ 推荐使用activemq, 环境都是java

### 序列化协议
+ 序列化（编码）是将对象序列化为二进制形式（字节数组），主要用于网络传输、数据持久化等；
+ 反序列化（解码）则是将从网络、磁盘等读取的字节数组还原成原始对象，主要用于网络传输对象的解码，以便完成远程调用。
+ 影响序列化性能的关键因素：序列化后的码流大小（网络带宽的占用）、序列化的性能（CPU 资源占用）；是否支持跨语言（异构系统的对接和开发语言切换）。
+ Java 默认提供的序列化：无法跨语言、序列化后的码流太大、序列化的性能差
+ **XML** 优点：人机可读性好，可指定元素或特性的名称。缺点：序列化数据只包含数据本身以及类的结构，不包括类型标识和程序集信息；
  + 只能序列化公共属性和字段；不能序列化方法；文件庞大，文件格式复杂，传输占带宽。
  + 适用场景：当做配置文件存储数据，实时数据转换。
+ **JSON** 是一种轻量级的数据交换格式
  + 优点：兼容性高、数据格式比较简单，易于读写、序列化后数据较小，可扩展性好，兼容性好、与 XML 相比，其协议比较简单，解析速度比较快。
  + 缺点：数据的描述性比 XML 差、不适合性能要求为 ms 级别的情况、额外空间开销比较大。
  + 适用场景（可替代xml）：跨防火墙访问、可调式性要求高、基于 Webbrowser 的 Ajax 请求、传输数据量相对小，实时性要求相对低（例如秒级别）的服务。
+ **Fastjson** 采用一种“假定有序快速匹配”的算法。
  + 优点：接口简单易用、目前 java 语言中最快的 json 库。
  + 缺点：过于注重快，而偏离了“标准”及功能性、代码质量不高，文档不全。
  + 适用场景：协议交互、Web 输出、Android 客户端
+ **Thrift** 不仅是序列化协议，还是一个 RPC 框架。
  + 优点：序列化后的体积小, 速度快、支持多种语言和丰富的数据类型、对于数据字段的增删具有较强的兼容性、支持二进制压缩编码。
  + 缺点：使用者较少、跨防火墙访问时，不安全、不具有可读性，调试代码时相对困难、不能与其他传输层协议共同使用（例如 HTTP）、无法支持向持久层直接读写数据，即不适合做数据持久化序列化协议。
  + 适用场景：分布式系统的 RPC 解决方案
+ **Avro**，Hadoop 的一个子项目，解决了 JSON 的冗长和没有 IDL 的问题。
  + 优点：支持丰富的数据类型、简单的动态语言结合功能、具有自我描述属性、提高了数据解析速度、快速可压缩的二进制数据形式、可以实现远程过程调用 RPC、支持跨编程语言实现。
  + 缺点：对于习惯于静态类型语言的用户不直观。
  + 适用场景：在 Hadoop 中做 Hive、Pig 和 MapReduce的持久化数据格式。
+ **Protobuf** 将数据结构以.proto 文件进行描述，通过代码生成工具可以生成对应数据结构的POJO 对象和 Protobuf 相关的方法和属性。
  + 优点：序列化后码流小，性能高、结构化数据存储格式（XML JSON 等）、通过标识字段的顺序，可以实现协议的前向兼容、结构化的文档更容易管理和维护。
  + 缺点：需要依赖于工具生成代码
  + 适用场景：对性能要求高的 RPC 调用、具有良好的跨防火墙的访问属性、适合应用层对象的持久化
+ **protostuff** 基于 protobuf 协议，但不需要配置 proto 文件，直接导包即可
+ **Jboss marshaling** 可以直接序列化 java 类， 无须实 java.io.Serializable 接口
+ **Message pack** 一个高效的二进制序列化格式
+ **Hessian** 采用二进制协议的轻量级 remoting onhttp 工具
+ **kryo** 基于 protobuf 协议，只支持 java 语言,需要注册（Registration），然后序列化（Output），反序列化（Input）

### 集群、分布式、SOA、微服务的概念及区别
+ 集群:不同服务器部署同一套应用服务对外提供访问，实现服务的负载均衡或者互备(热备，主从等)，指同一种组件的多个实例,形成的逻辑上的整体。单个节点可以提供完整服务。集群是物理形态
+ 分布式:服务的不同模块部署在不同的服务器上，单个节点不能提供完整服务，需要多节点协调提供服务(也可以是相同组件部署在不同节点、但节点间通过交换信息协作提供服务)，分布式强调的是工作方式
+ SOA:面向服务的架构，一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用。
  + 中心化实现:ESB(企业服务总线)，各服务通过ESB进行交互，解决异构系统之间的连通性，通过协议转换、消息解析、消息路由把服务提供者的数据传送到服务消费者。很重，有一定的逻辑，可以解决一些公用逻辑的问题。
  + 去中心化实现:微服务
+ 微服务︰在SOA上做的升华，微服务架构强调的一个重点是业务需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成
  + 服务单一职责
  + 轻量级通信:去掉ESB总线，采用restapi通信

### 分布式事务有哪些解决方案
+ 基于XA协议的:两阶段提交和三阶段提交，需要数据库层面支持
+ 基于事务补偿机制的:TCC，基于业务层面实现
+ 本地消息表:基于本地数据库+mq，维护本地状态(进行中)，通过mq调用服务，完成后响应一条消息回调，将状态改成完成。需要配合定时任务扫表、重新发送消息调用服务，需要保证幂等
+ 基于事务消息:mq

+ 第一阶段（ prepare） :每个参与者执行本地事务但不提交，进入ready状态，并通知协调者已经准备就绪。
+ 第二阶段（commit）当协调者确认每个参与者都ready后，通知参与者进行commit操作;如果有参与者fail，则发送rollback命令，各参与者做回滚。
+ 问题:
  + 单点故障:一旦事务管理器出现故障，整个系统不可用(参与者都会阻塞住)
  + 数据不一致:在阶段二，如果事务管理器只发送了部分commit消息，此时网络发生异常，那么只有部分参与者接收到rommit消息，也就是者说只有部分参与者提交了事务，使得系统数据不一致。
  + 响应时间较长:参与者和协调者资源都被锁住，提交或者回滚之后才能释放
  + 不确定性:当协事务管理器发送commit之后，并且此时只有一个参与者收到了commit，那么当该参与者与事务管理器同时宕机之后，重新选举的事务管理器无法确定该条消息是否提交成功。

+ 三阶段协议:主要是针对两阶段的优化，解决了2PC单点故障的问题，但是性能问题和不一致问题仍然没有根本解决
  引入了超时机制解决参与者阻塞的问题，超时后本地提交，2pc只有协调者有超时机制

+ 第一阶段:Cancommit阶段，协调者询问事务参与者，是否有能力完成此次事务。
  + 如果都返回yes，则进入第二阶段
  + 有一个返回no或等待响应超时，则中断事务，并向所有参与者发送abort请求
+ 第二阶段:PreCommit阶段，此时协调者会向所有的参与者发送PreCommit请求，参与者收到后开始执行事务操作。参与者执行完事务操作后（此时属于未提交事务的状
  态），就会向协调者反馈"Ack"表示我已经准备好提交了，并等待协调者的下一步指令。
+ 第三阶段:DoCommit阶段，在阶段二中如果所有的参与者节点都返回了Ack，那么协调者就会从""预提交状态"转变为"提交状态"。然后向所有的参与者节点发送
  "doCommit"请求，参与者节点在收到提交请求后就会各自执行事务提交操作，并向协调者节点反馈"Ack""消息，协调者收到所有参与者的Ack消息后完成事务。相反，
  如果有一个参与者节点未完成PreCommit的反馈或者反馈超时，那么协调者都会向所有的参与者节点发送abort请求，从而中断事务。

#### TCC
+ TCC (补偿事务): Try、Confirm、Cancel
+ 针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作
+ Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作既回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务
  的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel操作若执行败，TM会进行重试。
+ TCC模型对业务的侵入性较强，改造的难度较大，每个操作都需要有try、confirm、cancel三个接口实现
+ TCC中会添加事务日志，如果Confirm或者Cancel阶段出错，则会进行重试，所以这两个阶段需要支持幂等;如果重试失败，则需要人工介入进行恢复和处理等。

#### RPC
+ RPC要求在调用方中放置被调用的方法的接口。调用方只要调用了这些接口，就相当于调用了被调用方的实际方法，十分易用
  于是，调用方可以像调用内部接口一样调用远程的方法，而不用封装参数名和参数值等操作。包含
+ 1.动态代理，封装调用细节
+ 2.序列化与反序列化，数据传输与接收
+ 3.通信，可以选择七层的http，四层的tcp/udp
+ 4.异常处理等

+ 首先，调用方调用的是接口，必须得为接口构造一个假的实现。显然，要使用动态代理。这样，调用方的调用就被动态代理接收到了
+ 第二，动态代理接收到调用后，应该想办法调用远程的实际实现。这包括下面几步:
  + 识别具体要调用的远程方法的IP、端口
  + 将调用方法的入参进行序列化
  + 通过通信将请求发送到远程的方法中
+ 这样，远程的服务就接收到了调用方的请求。它应该:
  + 反序列化各个调用参数
  + 定位到实际要调用的方法，然后输入参数，执行方法
  + 按照调用的路径返回调用的结果

+ RMI:远程方法调用, java中用于实现RPC的-种机制，RPC的java版本, 是2EE的网络调用机制，跨JVM调用对象的方法，面向对象的思维方式
+ 直接或间接实现接口`java.rmi.Remote` 成为存在于服务器端的远程对象，供客户端访问并提供一定的服务
+ 远程对象必须实现java.rmi.server.UniCastRemoteObject类,这样才能保证客户端访问获得远程对象时，该远程对象将会把自身的一个拷贝以Socket的形式传输给客
  户端，此时客户端所获得的这个拷贝称为“存根”，而服务器端本身已存在的远程对象则称之为“骨架”。其实此时的存根是客户端的一个代理， 用于与服务器端的通信,
  而骨架也可认为是服务器端的一个代理,用于接收客户端的请求之后调用远程方法来响应客户端的请求。

### 分布式id生成方案
+ uuid
  + 1、当前日期和时间 时间戳
  + 2、时钟序列。 计数器
  + 3，全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得。
  + 优点:代码简单，性能好(本地生成，没有网络消耗)，保证唯一(相对而言，重复概率极低可以忽略)
  + 每次生成的ID都是无序的，而且不是全数字，且无法保证趋势递增。
  + UUID生成的是字符串，字符串存储性能差，查询效率慢，写的时候由于不能产生顺序的append操作，需要进行insert操作，导致频繁的页分裂，这种操作在记录占用空间比较大的情况下，性能下降比较大，还会增加读取磁盘次数
  + UUID长度过长，不适用于存储，耗费数据库性能。
  + ID无一定业务含义，可读性差。
  + 有信息安全问题，有可能泄露mac地址
+ 数据库自增序列
  + 单机模式: 实现简单，依靠数据库即可，成本小，ID数字化，单调自增，满足数据库存储和查询性能，具有一定的业务可读性。
    缺点: 强依赖DB，存在单点问题，如果数据库宕机，则业务不可用。
    DB生成ID性能有限，单点数据库压力大，无法扛高并发场景。
    信息安全问题，比如暴露订单量，ur1查询改一下id查到别人的订单
  + 数据库高可用:多主模式做负载，基于序列的起始值和步长设置，不同的初始值，相同的步长，步长大于节点数
    优点: 解决了ID生成的单点问题，同时平衡了负载。
    缺点: 系统扩容困难:系统定义好步长之后，增加机器之后调整步长困难。
      数据库压力大:每次获取-一个ID都必须读写一次数据库。
      主从同步的时候对数据要求比较严谨的话查master主库。
+ Leaf-segment：采用每次获取一个ID区间段的方式来解决，区间段用完之后再去数据库获取新的号段，这样一来可以大大减轻数据库的压力
  + 核心字段: biz_ tag, max_id, step
    biz_ tag用来区分业务，max_id表示该 biz_tag目前所被分配的ID号段的最大值，step 表示每次分配的号段长度，
    原来每次获取ID都要访问数据库，现在只需要把Step设置的足够合理如1000，那么现在可以在1000个ID用完之后再去访问数据库
  + 优点: 扩张灵活，性能强能够撑起大部分业务场景。 
    ID号码是趋势递增的，满足数据库存储和查询性能要求。
    可用性高，即使ID生成服务器不可用，也能够使得业务在短时间内可用，为排查问题争取时间。
  + 缺点: 可能存在多个节点同时请求ID区间的情况，依赖DB
  + 双buffer: 将获取一个号段的方式优化成获取两个号段，在一个号段用完之后不用立马去更新号段，还有一个缓存号段备用，这样能够有效解决这种冲突问题，而且采用双buffer的方式，在当前号段消耗了10%的时候就去检查下一个号段有没有准备好，如果没有准备好就去更新下一个号段，当当前号段用完了就切换到下一个已经缓存好的号段去使用，同时在下一个号段消耗到10%的时候，又去检测下-一个号段有没有准备好，如此往复。
  优点: 基于JVM存储双buffer的号段，减少了数据库查询，减少了网络依赖，效率更高。
  缺点: segment号段长度是固定的，业务量大时可能会频繁更新号段，因为原本分配的号段会一下用完如果号段长度设置的过长，但凡缓存中有号段没有消耗完，其他
  节点重新获取的号段与之前相比可能跨度会很大。动态调整Step

+ 基于redis、 mongodb、 zk等中间件生成
+ 雪花算法：生成一个64bit的整性数字
  + 第一位符号位固定为0，41位时间戳，10位workId, 12位序列号，位数可以有不同实现
  + 优点: 每个毫秒值包含的ID值很多，不够可以变动位数来增加，性能佳(依赖workId的实现)。
    时间戳值在高位，中间是固定的机器码，自增的序列在低位，整个ID是趋势递增的。
    能够根据业务场景数据库节点布置灵活挑战bit位划分，灵活度高。
  + 缺点: 强依赖于机器时钟，如果时钟回拨，会导致重复的ID生成，所以一般基于此的算法发现时钟回拨，都会抛异常理，阻止ID生成，这可能导致服务不可用

### 接口的幂等性
+ 唯一id。每次操作,都根据操作和内容生成唯一 的id, 在执行之前先判断id是否存在，如果不存在则执行后续操作，并且保存到数据库或者redis等。
+ 服务端提供发送token的接口，业务调用接口前先获取token,，然后调用业务接口请求时，把token携带过去,判断token是否存在redis中，存在表示第一次请求, 可以继续执行业务,执行业务完成后，最后需要把redis中的token删除
+ 建去重表: 将业务中有唯一标识的字段保存到去重表,如果表中存在，则表示已经处理过了
+ 版本控制: 增加版本号，当版本号符合时,才能更新数据
+ 状态控制: 例如订单有状态已支付未支付支付中支付失败，当处于未支付的时候才允许修改为支付中等

万孝国/java_study

简介

发行版

贡献者

近期动态

万孝国/java_study .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

万孝国/java_study