doubbo（soa核心的架构）：首先得提供数据（provide），提供出来的数据（接口）得让consumer知道，他就注册到注册中心（redistery），cosumer就会订阅注册中心，当集群的时候或者增加了节点因为consumer已经订阅了register就会推送consumer就直接调用provider，但是还要监管（monitor）节点的状态。
rpc（远程调用）：
consumer服务的调用端，provide服务的提供端，因为是互相调用他们都占一个jvm他们互相调用的时候在网络上传输，他们传输的是对象在网上怎么传输就得变成0010的东西所以就有序列化和反序列化。远程代理，代理的就是provide。
他们都干了什么呢？
consumer连接provide我要业务的分离就可以用线程池，
consumer是怎么连接管理的：
proxy就是远程代理
webservice对外提供服务（没有数据的），通过网络获取数据，有就返回，没有就去注册一下，注册成功就返回去，调用用的都是rpc，如果web发了user没有返回结果就会阻塞，阻塞的是什么线程。业务服务线程，还有一个技术io线程这两个线程，还要考虑到阻塞到哪里了是业务服务线程，因为如果阻塞到io线程的话业务服务线程就发送不了数据了。数据库连接的就是一个请求就一个连接，因为他要事务。那业务线程是怎么阻塞的：user返回数据的时候返回到resbao，如果没有响应就阻塞，如果有响应就唤醒，事件机制。如何确定发送的包和返回的包一 一对应就可以用timeout，队列得设置多大啊？
压榨provide的资源，无法就是cpu和线程：cpu主要和线程有关，内存主要和队列有关，往队列放的请求我们能不能控制不住，因为他是按用户量决定，剩下压榨的就只有CPU了，线程池分配的方案：
哪种方案更优秀：单列多线程，慢请求还是会受用户量影响。对慢请求友好就是有一个请求110秒没有处理完不会影响其他线程，但是还要考虑同步一致性的问题
多队列单线程：但是有一种情况，每个线程都是110秒当没有处理完，另外一个请求过来了，就会越来越慢。但是他没有数据一致性的问题
选哪种线程池方案更好第3种更好。
压测：
nacos本质上就是一个jar包连一下就行了：provide需要注册，consumer去订阅，右边的的控制台类似于监控系统就可以动态的调整的service负载调低一点，
心跳是随机跳的
就是把服务注册到注册中心（也就是临时节点、业务）这种方式采用的是心跳机制，和长连接的心跳还不一样，
长连接的心跳 -> 一遍b端，一遍s端，建立一个长连接，如果没有数据传输这条连接就没有什么用了，会断开，节省一下服务资源，为了不让他断开，就发一个没有实际用途的包，
nacos了，就是发一些和节点有关联的包比如端口号什么的，注册中心就知道是不是好的，如果在一定的时间没有收到就进行一次标记，3次之后就会把这个节点信息就从注册中心剔除掉。
永久节点，比如持久化节点如mysql，redis但是都是别人开发好的，这些东西为了使我的注册中心不可能发一次心跳包但是又要做健康检查，注册中心去挑衅永久节点，这种方式叫探活，如果不给我反应，就标记不可用，因为我们是关不了永久节点，因为他还得保持其他启动
为什么服务注册和健康检查放在一起，因为心跳可以做的事情太多了
double生态注册中心一般用zk多一些，到时现在用nacos多一些。
user就是个人账号，namepace租户，这两个东西就是为了屏蔽注册中心实际的逻辑（数据的位置等等一些信息），
只要是集群就的考虑数据的一致性，数据的高可用，数据的通信。
他是接触了erueak的一些思想，做了一个升级优化。
nacos有3个节点他是一个集群，给服务提供注册provide，他也有6个节点，他注册数据都是完整的数据，每一个单机节点并不维护所有的provide节点的数据，每个nacos只维护自己的这6个节点。当provide注册到注册中心，连接上广播，当连上不是他维护的nacos由是他会通过查元数据是谁维护的，就会让他注册，就成为了最新的数据，但是其他nacos没有更新，就通过广播广播出去我维护了新的数据。这样保持数据的一致性。算法用的是哈希算法
可是当广播的时候是走网络的万一挂掉了数据就会不一致了，distro ap是轮询的保证最终一致性就好了，这个就借鉴了erueak的广播的协议保证数据一致性。
如果nacos作为配置中心，provide有xml、yml项目肯定是一个集群，由是整一个服务专门管理这些配置文件集中管理。数据一致性的时候用的就是raftcp协议。
sentinel主要功能就是入口流量控制的（他是一个jar包连一下就好了）：springcloud的对标的不维护了
就是提高微服务稳定性，控制资源，他的特征就是在应用程序开个后门，就是开一个端口让sentinel挂上去，去控制。
做流量控制的时候用的是什么算法：
列子：从谁的直播间，哪个介绍老师，可以享受什么优惠，这个得要多少if，又要去查表，调用服务，而且过来这个时间的代码就没用了，压力就很大。这个时候就可以用mq去做。我就可以把这个活动放到mq里
一个userid先发到风控服务，这个用户能不能下单。对于交易服务我只关系下单逻辑，扣减库存，我不管你的风控记录不记录。
真正的性能瓶颈在数据库，为了瞬间压力不压垮我的性能我把信息放到mq。切记mq不要乱用mq，因为mq挂了，
rockermq没有主从，但是他扩展强，可以设置主从。重业务可以用rockermq，如果重性能可以用kafka，因为他是顺序读顺序写，rockermq是顺序写，随机读。rabbitmq可靠消息传输
broker就是存储东西的，
commitlog是从上往下存的。dodespat线程是用来分发线程他会把topic发送给不同的消息队列。那consumer就可以连到消息队列取消息。消息队列存的是消息索引文件。
顺序写，随机读是如何保证性能的？
要是全的消息全部存到commitlog一个大的，那么就会越大你的指针跳动范围就越大，所以就把他切一下。
seta阿里出来的分布式事务的框架，他支持sa，支持2pc，支持at，强一致性，最终一致性他都支持。第一阶段是发两个请求，但是保不齐第二阶段第一个ok第二个不ok，这种情况就有毛病了，那就有三阶段提交多了个预提交
xa对性能会有损耗，业务上一般都是柔性事务，最终一致性
半消息只发给mq，不发给订阅方，执行一次rpc调用，（本地事务）本地事务成功了，就把半消息发给消息订阅方。但是有一个问题，第3步的时候，发了一个rpc但是·1消息发送发得知道这个是成功还是不成功，需要提供与一个需要入库本地事务查询的接口，查询成功了就commit没有成功就rollback
不管你发的什么消息我发你半消息就把topic变成rmq_sys…这个主体，这个主体是mq内部的，就没有consumer来订阅，那这个主体就一直放在mq里。然后op消息就是调用rpc有没有成功的时候告诉mq’消息接受op消息。
rocketmq事务消息原理：
生产者发送了一个消息在cimmitlog如果是事务消息就变成rmq_sys…这个主体，这快是半消息调用rpc如果成功就得告诉mq成功了，就commit从半消息重新放到cimmitlog写过时候是原来自己什么主体就是什么主体了如果是rollback就把这个消息给干掉。
响应时间：200毫秒
并发数：运维去感知
qps：每秒查询的数量 读的性能
tps：没秒执行的事务数量（update、delete） 写的性能
成就感：jvm调优