优点：解决方案、处理问题能力、架构优化/拓展能力

零、Zookeeper事务

事务id(主从同步Id-每次ack递增+1,64位存储（32位纪元号-leader号，32位自增号）)
每一个操作都将使节点接收到一个Zxid格式的时间戳
ZooKeeper的每个节点维护者两个Zxid值，为别为：cZxid、mZxid。
（1）cZxid：是节点的创建时间所对应的Zxid格式时间戳。
（2）mZxid：是节点的修改时间所对应的Zxid格式时间戳。
一个客户端发起的写请求打到follower时的整个流程。
1.follower将请求转发给leader。
2。leader发起Proposal原子广播事务提议，把消息广播给所有follower。
3.leader等待过半follower写log并返回ack后,将请求提交。
4.将这条日志广播给所有follower。
5.follower提交并给客户端返回。
假如此时发送写请求的follwer写失败了（失败的那小半数），客户端请求读的时候如果又正好请求到这个follwer，读写不一致问题出现，解决：
zookeeper 的读写一致不是在 server 做的，而是 server & client 配合的；client 会记录它见过的最大的 zxid （写成功的zkid），读取的时候，如果 server 发现 这条 zxid 比 server 端的最大 zxid 大，则此follwer抛出异常决绝请求，client 会自动重连到其他server（还在同一个 session） —— 最终会落到有新数据的 server 上，因为半数已经同意；
Zookeeper集群机器数为什么是奇数（选举出来的zkid不是最大值：1、leader死亡复活2、leader脑裂后占少数（3个节点1:2））
①、集群脑裂时（leader通信部分不可达）导致leader选举：3台机：2>2/3=1.5(脑裂A1台机，脑裂B2台机)
②、集群脑裂时（leader通信部分不可达）导致leader选举：4台机：2不大于2/4=2(脑裂A2台机，脑裂B2台机)
③、情况①允许1个节点宕机，情况②也是允许一台机子宕机（1:3时集群可用），故性价比一样且情况②出错几率更高

一、Zookeeper同步机制

一、(Eureka（AP可用性容错性）-各节点平等，且有自我保护机制，15分钟内85%的节点没有正常心跳：1、不再移除异常心跳服务2、仍能接收新服务注册和查询3、恢复网络后同步新注册信息到其他节点
二、Zookeeper（CP一致性容错性）-master选举整个集群不可用，选举时长30-120s)
当各个节点已经自我恢复并选举出leader后(根据事务ID和服务器ID，大值当选)，leader就开始和follows进行数据同步了，具体的逻辑可以见{org.apache.zookeeper.server.quorum.LearnerHandler}中：
leader构建NEWLEADER包，内含leader最大数据的zxid, 广播给follows，然后leader根据follower数量为每个follower创建一个LearnerHandler线程来处理同步请求（FIFO数据队列，更新数据时往队列中添加）：leader主线程阻塞，等待超过半数follower同步完数据之后成为正式leader。
follower接收到NEWLEADER包后响应FOLLOWERINFO给leader，告知本方数据最大的zxid值； leader接收到回馈后开始判断：
如果follower和leader数据一致，则直接发送DIFF告知已经同步；
判断这一阶段内有无已经北提交的决议值，如果有，那么
a) 如果follower数据比leader少，leader发送DIFF包将有差异的数据同步过去，同时将follower没有的数据逐个发送commit包给follower要求记录下来；
b) 如果follower数据zxid更大（oldLeader挂了,newLeader当选之后,oldLeader复活作为follower），此时oldLeader取出当前最新的txid，去leader上查找，没有此txid，则丢弃本地的txid，再递归查找上一个txid，不一致就一直丢弃，直到找到与newLeader上txid一致，并且数据一致；从该txid往后开始同步数据
如果这一阶段没有提交的决议，直接发送SNAP包将快照同步给follower
以上消息完毕后，LEADER发送UPTODATE包告知follower当前数据已同步，等待follower的ACK完成同步过程。
Zookeeper leader 选举　　
半数通过(服务器为奇数的原因)
– 3台机器 挂一台 2>3/2
– 4台机器 挂2台 2！>4/2

二、Redis：（1、内存操作2、单线程无上下文切换及锁冲突3、hash结构存储4、io多路复用）

Redis为什么快：
1、纯内存操作2、单线程无上下文切换及锁（但是RDB持久化时会fork一个子进程写新文件覆盖旧RDB）
3、hash数据结构简单（string、list、set、hash）4、IO多路复用（多个网络连接复用一个线程，空闲时阻塞，有一个或多个流有io事件时，系统组件回调通知，redis轮询所有的（发出事件的）流并依次顺序的处理就绪的流）
多个socket链接复用同一个线程处理;使用epoll策略，实现哪些socket有通讯，处理那些socket、 高效
只有存在大量的空闲连接和不活跃的连接的时候，使用epoll的效率才会比select/poll高
删除策略及剔除算法：一、主动删除（每秒10次检查，每次检查100个设置了过期时间的key，超过25%过期则删除后重复此动作） 二、被动删除（使用时检查） 
三、超过最大内存触发清理算法（基于设置了过期时间且内存将满条件）：
1、最少使用 2、最少使用次数 3、快过期 4、随机 5、不淘汰，写入报错
64位系统Redis的存储极限是系统中的可用内存值
Redis是个单线程模型，客户端过来的命令是按照顺序执行的，所以想要一次添加多条数据的时候可以使用管道，或者使用一次可以添加多条数据的命令
SLOWLOG [get/reset/len]
slowlog-log-slower-than  //它决定要对执行时间大于多少微秒(microsecond，1秒 = 1,000,000 微秒)的命令进行记录  
slowlog-max-len   //它决定 slowlog 最多能保存多少条日志  
当发现redis性能下降的时候可以查看下是哪些命令导致的
redis进行RDB快照的时机（在配置文件redis.conf中）
save 900 1  //表示900秒内至少一个键被更改则进行快照。  
save 300 10  //表示300秒内10条被更改则快照  
save 60 10000  //60秒内10000条  
Redis自动实现快照的过程
1、redis使用fork函数复制一份当前进程的副本(子进程)
2、父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件
3、当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此，一次快照操作完成。
注意：redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。
aof方式的持久化是通过日志文件的方式。默认情况下redis没有开启aof，可以通过参数appendonly参数开启。
appendonly yes  
aof文件的保存位置和rdb文件的位置相同，都是dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改
appendfilename appendonly.aof  
redis写命令同步的时机
appendfsync always 每次都会执行  
appendfsync everysec 默认 每秒执行一次同步操作（推荐，默认）  
appendfsync no不主动进行同步，由操作系统来做，30秒一次  
aof日志文件重写
auto-aof-rewrite-percentage 100(当目前aof文件大小超过上一次重写时的aof文件大小的百分之多少时会再次进行重写，如果之前没有重写，则以启动时的aof文件大小为依据)  
auto-aof-rewrite-min-size 64mb  
//测试管道批量插入（redis的pipeline(管道)功能在命令行中没有，但是java的客户端(jedis)中是可以使用的）  
public static void testPip() {  long currentTimeMillis = System.currentTimeMillis();  Jedis jedis = new Jedis("192.168.33.130", 6379);  Pipeline pipelined = jedis.pipelined();  for (int i = 0; i < 1000; i++) {  pipelined.set("bb" + i, i + "bb");  }  pipelined.sync();  long endTimeMillis = System.currentTimeMillis();  System.out.println(endTimeMillis - currentTimeMillis);  
}  
在插入更多数据的时候，管道的优势更加明显：测试10万条数据的时候，不使用管道要40秒，实用管道378毫秒。

三、SpringCloud常用组件：

1、注册中心：Eurake/Nacos  2、配置中心Appolo/Nacos 3、网关Gateway 
4、断路器Histric（@FeignClient(value = "giveu-shop-fn-service", fallback = RepaymentServiceHystrixImpl.class)）每当20个请求中，有50%失败（ribbon时才真正去调用下级服务）时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。直到5s（断路重试设置时间）之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开熔断和降级：从可用性和可靠性触发，都是为了防止系统崩溃；服务熔断一般是下游服务故障导致的，而服务降级一般是从整体系统负荷考虑，由调用方控制
5、负载均衡ribbon第一步：拦截器获取应用名 @configuration LoadBalancerAutoConfiguration是Ribbon的自动配置类，在这个配置类里面配置了一个拦截器，该拦截器会拦截所有请求，这就是Ribbon的入口LoadBalancerInterceptor的intercept方法（当远程调用的时候都会被拦截器拦截）第二步：通过应用名获取服务列表负载均衡器ZoneAwareLoadBalancer implement ILoadBalancer 是获取服务列表的重要组件第三步：从列表中获取具体服务ZoneAwareLoadBalancer定义了获取服务的方法，但是该方法最终调用的是父类BaseLoadBalancer  chooseServer方法接口层级:IRule(定义choose方法)->AbstractLoadBalancerRule负载均衡策略的抽象类，在该抽象类中定义了负载均衡器ILoadBalancer对象，该对象能够在具体实现选择服务策略时，获取到一些负载均衡器中维护的信息作为分配依据，并以此设计一些算法来实现针对特定场景的高效策略->RandomRule（随机，rand.nextInt(serverCount)函数来获取一个随机数）、RoundRobinRule（线性轮训，count计数变量）、RetryRule（重试-线性轮训选到的异常且在重试时间就重试）、WeightedResponseTimeRule（权重-根据服务响应时间分配权重-每30秒更新一次）、BestAvailableRule（最空闲）、PredicateBasedRule（重写过滤条件后线性轮训）、ZoneAvoidanceRule(Finchley.SR1版本中默认均衡策略)ZoneAvoidanceRule是PredicateBasedRule的一个实现类，以ZoneAvoidancePredicate和AvailabilityPredicate组合过滤后线性轮训
6、模块化Http组件：FeignClient（服务之间调用默认使用的HttpURLConnection，效率非常低，需要重写为okhttp）
#PS(Dubbo负载策略：1、随机2、最少活跃3、一致性Hash-基于160个虚拟节点-携带相同的参数总是发送的同一个服务提供者)
#dubbo-admin主要是对路由规则，访问控制，权重调整等进行管控；；dubbo粒度较细，细微到方法级别
强依赖Zookeeper外部注册中心，且xml配置有硬编码，基于TCP二进制长连接，响应占优势
#springCloud-Gateway主要是对服务降级 ，访问控制，路由规则，权重调整(灰度) 等进行管控；；粒度较粗，到方法/实例级别
是微服务全家桶，约定优于配置，开箱即用
feign:# feign启用hystrix，才能熔断、降级# hystrix:# enabled: true# 启用 okhttp 关闭默认 httpclienthttpclient:enabled: false #关闭httpclient# 配置连接池max-connections: 200 #feign的最大连接数max-connections-per-route: 50 #fegin单个路径的最大连接数okhttp:enabled: true
Ribbon1、负载均衡策略Ribbon 默认的策略是轮询，从我们前面讲解的例子输出的结果就可以看出来，Ribbon 中提供了很多的策略，这个在后面会进行讲解。我们通过配置可以指定服务使用哪种策略来进行负载操作。2. 超时时间# 请求连接的超时时间ribbon.ConnectTimeout=2000# 请求处理的超时时间ribbon.ReadTimeout=50003. 并发参数# 最大连接数ribbon.MaxTotalConnections=500# 每个host最大连接数ribbon.MaxConnectionsPerHost=500
hystrix:threadpool:default:coreSize: 200 #并发执行的最大线程数，默认10maxQueueSize: 1000 #BlockingQueue的最大队列数，默认值-1queueSizeRejectionThreshold: 800 #即使maxQueueSize没有达到，达到queueSizeRejectionThreshold该值后，请求也会被拒绝，默认值5

线程池变量：核心线程数、最大线程数、超时时间

为什么要用线程池:
1.减少了创建和销毁线程的次数，每个工作线程都可以被重复利用，可执行多个任务。
2.可以根据系统的承受能力，调整线程池中工作线线程的数目，防止因为消耗过多的内存，而把服务器累趴下(每个线程需要大约1MB内存，线程开的越多，消耗的内存也就越大，最后死机)。
Java通过Executors提供四种线程池，分别为：* newCachedThreadPool创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。* newFixedThreadPool 创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。* newScheduledThreadPool 创建一个定长线程池，支持定时及周期性任务执行。 * newSingleThreadExecutor创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。
定长线程池读取文件/Excel落地到数据库/队列(导入Excel用户信息或短信推送队列)
ExecutorService es = Executors.newFixedThreadPool(30);
一、无需反馈型
for (User user : excelLine) {exe.execute(new Thread(new Runnable() {@Overridepublic void run() {cacheService.push(user);}}));
}
二、需要反馈型
ExecutorService pool = Executors.newFixedThreadPool(5);
Future<Integer> future = pool.submit(new Callable<Integer>() {public Integer call() throws Exception {return cacheService.push(user);}
});
pool.shutdown();
System.out.println(future.get());
Dubbo和SpringCloud
NIO:同步非阻塞，一个请求一个线程，客户端的连接请求都会注册到多路复用器上，多路复用器轮询到连接有IO请求时才启动一个线程进行处理；
适合连接数目多，连接比较短的架构，比聊天服务器，并发局限于应用中，编程比较复杂；
AIO:异步非阻塞，连接数目多且连接比较长的架构，比如相册服务器，客户端的I/O请求都是由OS先完成了再通知服务器应用去启动线程进行处理，JDK1.7开始支持
dubbo注册到zk的有：ip、dubbo端口、注册协议（dubbo）、版本号(version=1.0.0)、接口名（interface=con.test.UserService）、side（提供者/消费者）
zk通过树形文件存储的 ZNode 在 /dubbo/Service 目录下面建立了四个目录，分别是：
1、Providers2、Consumers3、Routers（消费者路由策略）4、Configurators提供者动态配置URL
服务提供者在启动的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址

注意点：
1）对于核心的服务中心，去除dubbo超时重试机制，并重新评估设置超时时间。（重试会使请求变为正常值的retries倍，容易引起服务雪崩）
2）对NULL数据进行缓存，防止出现缓存的变相击穿问题
3）服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑
dubbo-admin：控制路由分发、访问控制（黑白名单）、服务状态查看
Dubbo负载：1、随机2、最少活跃3、一致性Hash-基于160个虚拟节点-携带相同的参数总是发送的同一个服务提供者)
@Reference(loadbalance="roundrobin") 
Dubbo限流：设置服务端接口/方法executes请求上限（默认超出200报错）--@Reference(executes="50")
Dubbo熔断：设置服务端timeout，超时执行mock方法---------------------@Reference(timeout="1000",mock="userServiceMock")可借助外部组件@HystrixCommand(fallbackMethod="userServiceMock")或者sentinel-dubbo-adapter可视化限流降级
springcloud负载：ribbon配置负载策略：随机、线性轮询（默认）、最空闲、权重、过滤后线性---ribbon.ConnectTimeout=2000 # 请求连接的超时时间---ribbon.ReadTimeout=5000 # 请求处理的超时时间---ribbon.MaxTotalConnections=500 # 并发最大连接数---ribbon.MaxConnectionsPerHost=500# 并发每个host最大连接数---serviceA.ribbon.NFLoadBalancerRuleClassName=com.netflix.loadbalancer.RandomRule（Ribbon中没有通用的负载均衡策略配置方案）
springcloud限流：---hystrix.threadpool.default.coreSize=200（并发执行的最大线程数，默认10）---hystrix.threadpool.default.maxQueueSize=1000（BlockingQueue的最大队列数，默认值-1）
springcloud熔断：5s内20个请求中50%都失败则打开断路器，5s后重试1、按service线程池隔离2、按总线程失败百分比信号量隔离---@HystrixCommand(fallbackMethod = "userServiceMock",threadPoolKey = "licenseByOrgThreadPool",threadPoolProperties = {@HystrixProperty(name = "coreSize", value="30"),@HystrixProperty(name = "maxQueueSize" value="10"),},commandPoolProperties = {@HystrixProperty(name="circuitBreaker.requestVolumeThreshold", value="10"),//滑动窗口的大小，默认为20 @HystrixProperty(name="circuitBreaker.sleepWindowInMilliseconds", value="7000"),//熔断器打开7s，过多长时间，熔断器再次检测是否把熔断器关闭，默认为5000，即5s钟 @HystrixProperty(name="circuitBreaker.errorThresholdPercentage", value="50")//错误率，默认50%})
限流算法：计数器、滑动窗口、漏桶、令牌桶
基于Redis 实现限流
1、计数器算法：
基于redis的incrby 加一和decrby 操作，来控制分布式系统中计数器。
2、令牌桶算法：
基于 Redis 的 list接口可以实现令牌桶令牌补充和令牌消耗操作。
Hystrix:
常用线程池隔离，强依赖隔离策略实现，上下文切换损耗大且使机器资源碎片化
针对不同的资源分别创建不同的线程池。将每个类型的业务请求封装成对应的命令请求，比如查询订单->订单Command，查询用户->用户Command。每个类型的Command对应一个线程池。创建好的线程池是被放入到ConcurrentHashMap中。即使订单Command挂了或资源耗尽也不影响其他commond(commond key,commond group)
信号量隔离1、限制对资源调用的并发量或2、单位时间失败比率，但是对慢调用只能等待超时,无法自动降级
Sentinel：
只需考虑是否需要保护，任何时候可通过控制台（且支持外部数据源配置动态规则）实时修改规则-设置用什么去保护（1、1秒内持续5个平均响应时长超阈值2、1秒内失败比率3、1分钟内失败比率）
不仅可以基于信号量控制并发数（失败比率），还能基于平均响应时间熔断及慢启动预热/匀速器

杂谈

除了synchonized还能实现锁：atomic、volitile、reenTrantLock、threadLocal
java.util.concurrent
atomic、ReentrantLock、ConcurrentHashMap、CopyOnWriteArrayList、CountDownLatch、CyclicBarrier
ExecutorService、Future、Callable、LinkedBlockingQueue
年轻代为什么用复制算法：
1、在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法。只需要付出少量存活对象的复制成本就可以完成收集。
2、老年代中因为对象存活率高、没有额外空间对他进行分配担保，就必须用标记-清除或者标记-整理
GCRoots:栈引用对象、静态属性引用对象、方法区常量引用对象
JDK7之前:CMS-物理分区标记清除并发收集，占用CPU产生碎片
JDK7:G1-逻辑分区标记整理，增量清理
JDK11：ZGC-动态分区，着色指针读屏障防止StopTheWorld
AOP:启用了@Aspect的类作为方面Bean，调用目标方法时触发拦截器，通过 getProxy 动态生成并调用目标对象的代理类（实现的接口数量是否大于0）执行前置/后置/环绕增强
JDK动态代理（实现接口）：利用拦截器（InvovationHander）和反射动态生成代理类
CGLIB（继承业务类-不能为final）：
公平锁：线程严格按照先进先出(FIFO)的顺序, 获取锁资源
非公平锁：拥有锁的线程在释放锁资源的时候, 当前尝试获取锁资源的线程可以和等待队列中的第一个线程竞争锁资源（但是已经进入等待队列的线程, 依然是按照先进先出的顺序获取锁资源）
volatile内存可见，它主要有两个特性：
一. 保证共享变量对所有线程的可见性（对声明了volatile的变量进行写操作，JVM就会向处理器发送一条Lock前缀的指令，将这个缓存行的数据写回内存。在读取一个volatile类型的变量时，不会从线程私有数据栈中取得变量的值，而是强制从公共堆栈中取得变量的值）；
二. 禁止指令重排序优化（多核CPU乱序执行方法块代码）。
风控接口查询规则：先本地后接口，先命中式后查询式
风控三要素：黑名单、反欺诈、评分卡
架构流程：优化SQL/索引-加缓存服务器-读写分离-垂直分布式应用/垂直分表-水平分表
秒杀：1、（12306分时分段售票？）前端做防重点-后端限制uid请求数（如果发现某个IP请求频率很高，可以给它弹出一个验证码或者直接禁止它的请求）-redis做decre扣减缓存库存（redis单秒11W读8W写）-放入队列（限制同时请求DB量）落地数据库-预锁定-用户支付-锁定/真实扣减库存-物流
2、尽量避免热点key的同时重建（随机数控制同一时间只有一个线程重建或由业务层去控制重建时间）
优惠券：面值、条件金额、最多减免金额、有效期类型、“动态”有效期、用券渠道、用券门店、参与商品（分摊优惠及运费）、平台券（注册礼包/平台活动）/商户券、满减券/折扣券
HashMap在jdk1.8之前（segement链表）是插入头部的，在jdk1.8中（链接+红黑树）是插入尾部的。
#ConcurrentHashMap jdk8:1、取消segments字段，直接采用transient volatile HashEntry<K,V>[] table保存数据，并发通过Synchronized和CAS控制2、将jdk7原先table数组＋单向链表的数据结构，变更为table数组＋单向链表＋红黑树
存取（Synchronized-1、低粒度加锁不比ReentrantLock差2、内存占用比lock小）通过hash值跟数组长度取模来决定放在数组的哪个index下标，如果出现放在同一个位置的时候，优先以链表的形式存放，在同一个下标的个数大于8小于64的时候，则会扩容数组。如果数组的长度大于等于64了的话，在会将该节点的链表转换成树；；取元素的时候通过key的hash和key查找链表或树get不用加锁volatile可以修饰数组，只是意思和它表面上看起来的样子不同。举个栗子，transient volatile Node<K,V>[] table 是指table的地址是volatile的而不是table元素的值是volatile的ConcurrentHashMap get操作可以无锁是由于Node的元素val和指针next是用volatile修饰的，在多线程环境下线程A修改结点的val或者新增节点的时候是对线程B可见的。//可以看到这些都用了volatile修饰： 1、volatile V val; 2、volatile Node<K,V> next;获取size每次put时调用addCount+1;addCount先使用cas修改basecount,如果多个线程同时修改导致addCount失败，调用fullAddCount通过ThreadLocalRandom和cas加锁放入CounterCell[]数组如果fullAddCount也没拿到锁，执行自旋for (;;)统计累加count时，size=basecount+遍历CounterCell[].value(static final class CounterCell里的变量volatile long value)
同一个线程多次调用start()方法，第一次会正常运行（threadStatus==0），后面会报线程参数状态异常（if(threadStatus!=0) throw new IllegalThreadStateException()）
1、单例对象属性循环依赖：A构建-从第一级单例缓存池获取->从第二级提前曝光的单例缓存池获取（构造函数初始化完成属性未完成-内存地址确定）->从第三级单例工厂创建（拿到以后从第三级挪到第二级）发现依赖B，创建B->发现依赖A->从提前曝光的单例缓存缓存A的半成品（无属性）->B初始化完成->A拿到了属性B也初始化完成
2、AOP底层通过后置处理器BeanPostProcessor实现：该接口定义了两个方法（postProcessBeforeInitialization postProcessAfterInitialization），分别在bean实例化之后放到我们的容器之前和之后去执行，方法的返回值为一个object，这个object就是我们存在于容器的对象了（所以这个位置可以对我们的bean做一个动态的修改，替换等等操作
3、在容器启动，为对象赋值的时候，遇到@Autowired注解，会用后置处理器机制，来创建属性的实例，然后再利用反射机制，将实例化好的属性，赋值给对象上，这就是Autowired的原理
4、拦截器：调用目标方法getHandler时初始化并遍历拦截器数组，通过 getProxy 动态生成并调用目标对象的代理类（实现的接口数量是否大于0）执行前置/后置/环绕增强
5、spring三种注入方式：属性注入、构造函数注入、接口注入
千万级大表优化：1、优化sql和索引（组合索引、失效索引（左like|拿数字查询字符|不等于））2、缓存服务器3、主从读写分离4、垂直分表5、水平分表
Redis的性能极高，读的速度是110000次/s,写的速度是81000次/s
大文件：1、文件切割（100W行的单文件读取到100个1W行分隔文件）
对账调度（按通道/订单类型）每天定时从支付通道服务器上下载对账单（对账单错误需要及时通知通道方重发对账单）->使用ZGC快速处理垃圾回收->文件读取入库做持久化（每天半夜将10天前的订单文件移到另外的云盘）：单线程读取 while ((lineStr = bufferedReader.readLine()) != null) 多线程写入->（从从库取数据通过pipeline通道批量入redis缓存）执行select  concat(channel_id, ':', order_id , ':' , HASH_MD5(channel_id , order_id , amount , status , timestamp1 ,…) )  as hashid from table 得到对应的SET集合分批比对redis的sdiff（根据时间优先查询出最小id和最大id，然后再根据id，分批查询订单数据；直接比对订单字符串而不转对象减少序列化）->差异入库->差异处理(补记账回调业务/人工)->缓存清理->mongoDB批量读取清结算
Mybatis configuration类通过Executor(执行增删改查)、ParameterHandler、StatementHandler、ResultHandler来完成数据库操作并返回处理结果
设计模式：
spring:单例Bean、工厂BeanFactory、代理AOP动态代理、模板方法JDBCTemplate、观察者Listener、适配器Advice（前置before、后置after、环绕Around、Throws抛异常后）
mybatis:单例LogFactory、工厂SqlSessionFactory-MapperProxyFactory、代理MapperProxy、模板方法BaseExecutor和SimpleExecutor、适配器对jdbc、log4j等各种日志框架的适配

RabitMQ

一、RabbitMQ的exchange模式有：fanout（广播模式-绑定到路由器的都能收到）、direct（点对点指定routingkey，RabbitMQ的默认模式）、topic（模糊匹配routingkey）
二、为什么要使用RabbitMQ?
①在分布式系统下具备异步，削峰，负载均衡等一系列高级功能;
②拥有持久化的机制，进程消息，队列中的信息也可以保存下来。
③实现消费者和生产者之间的解耦。
④达到同步变异步的效果，同步下单进入队列，后台进行逻辑下单
三、RabbitMQ中重要的角色有：生产者、消费者和代理（MQ本身）
四、如何确保消息接收方消费了消息
①、消息确认机制
②消息持久化（队列持久化-消息持久化-交换器持久化）+补偿调度机制
③提供者使用唯一msgId，消费者使用唯一bizId
五、缺点：持久化操作降低了服务器吞吐量，增加系统复杂性

Http

1、使用多路复用的组件：redis、nio、http2
2、http1.1增加了持久连接和请求管道化
3、http2增加了IO多路复用和服务器推送
4、https借助CA认证证书解决防劫持问题（数字签名确认是对方发送的），运行在SSL之上，SLL又运行在TCP之上，通过非对称加密加密秘钥，对称加密加密内容，使用443端口（Http用的是80端口）

Docker和K8S

Docker是轻量级虚拟化，不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境（类似“沙箱”），
它启动时间很快，几秒钟就能完成。而且，它对资源的利用率很高（一台主机可以同时运行几千个Docker容器）。此外，它占的空间很小，虚拟机一般要几GB到几十GB的空间，而容器只需要MB级甚至KB级。
Docker本身并不是容器，它是创建容器的工具，是应用容器引擎：搭建-运行、一次搭建-到处能用
Docker技术的三大核心概念，分别是：镜像（Image）容器（Container）仓库（Repository）
镜像不包含任何动态数据，其内容在构建之后也不会被改变。也就是说，每次变出房子，房子是一样的，但生活用品之类的，都是不管的。谁住谁负责添置
负责对Docker镜像进行管理的，是Docker Registry服务（类似仓库管理员），最常使用的Registry公开服务，是官方的Docker Hub
如果想要将Docker应用于具体的业务实现，是存在困难的——编排、管理和调度等各个方面，都不容易。于是，人们迫切需要一套管理系统，对Docker及容器进行更高级更灵活的管理。
K8S，就是基于容器的集群管理平台，它的全称，是kubernetes。和Docker不同，K8S的创造者，是众人皆知的行业巨头——Google
一个K8S系统，通常称为一个K8S集群（Cluster）。主要包括两个部分：一个Master节点（主节点-负责管理和控制）一群Node节点（计算节点-工作负载节点，里面是具体的容器）
Master节点包括API Server、Scheduler、Controller manager、etcd。API Server是整个系统的对外接口，供客户端和其它组件调用，相当于“营业厅”。Scheduler负责对集群内部的资源进行调度，相当于“调度室”。Controller manager负责管理控制器，相当于“大总管”。
Node节点包括Docker、kubelet、kube-proxy、Fluentd、kube-dns（可选），还有就是Pod。
Pod是Kubernetes最基本的操作单元。一个Pod代表着集群中运行的一个进程，它内部封装了一个或多个紧密相关的容器。
除了Pod之外，K8S还有一个Service的概念，一个Service可以看作一组提供相同服务的Pod的对外访问接口。这段不太好理解，跳过吧。
Docker，不用说了，创建容器的。
Kubelet，主要负责监视指派到它所在Node上的Pod，包括创建、修改、监控、删除等。
Kube-proxy，主要负责为Pod对象提供代理。
Fluentd，主要负责日志收集、存储与查询。