shaolong1013的博客

一、整体性业务，即：虽然有多库多表，但都在同一个部门下，或者是可控的情况采用TCC、seata分布式事务框架，实现分布式事务性能问题：事务采用mysql，进行分库分表解决性能问题，哪个步骤慢，就解决哪个步骤的性能https://www.cnblogs.com/jajian/p/10014145.html二、非整体性业务2.1：下游只提供接口，比较中心化的服务，比如积分服务，京豆服务等此时只能用记录日志的方式，记录整个事务的执行状态，并且记录每一步的执行日志，预留好回滚需要的数据.

代码原理来自seata的分布式事务中，全局事务ID在多应用中的传递：https://blog.youkuaiyun.com/f4761/article/details/89077400https://blog.youkuaiyun.com/yunqiinsight/article/details/88343096如果是HTTP协议，多应用直接无代码侵入，生成全局唯一ID，并且在远程调用时，此ID在多个应用间传递：1、发送http请求时，进行拦截，并且之前在生成ID时，将ID放入ThreadLocal中，..

一、其中一个是固定坐标，比如商场、商店等，指定位置查找1公里范围内的地标使用es的geo进行查找，将固定地标的经纬度存入es中，在输入经纬度，匹配范围搜索出200km内的酒店GET /hotel_app/hotels/_search{"query": {"bool": {"must": [{"match_all": {}}],"filter": {"geo_dis...

一、leader选举1、无其他节点发送过来请求情况下，先选择自己，并发出通知2、有三种情况：1、获得大多数节点反馈，成为leader，通知其他所有节点，其他节点成为follower；2、其他节点成为leader，收到通知，将自己变为follower；3、无任何节点获取过半选票，测试随机等待一个时间后发出选票，避免多次无人过半，有的先发出请求有的后发出，先发出容易获得选票成为leader避免脑裂：1、必须获取过半的选票才能成为leader2、每个节点只有一票二、数据同步过程1.

1、长连采用HTTP而非TCP的主要考虑点是多语言的适配；2、采用异步servlet，单机可以支撑1W个连接，也就是一万个客户端，一般10台服务器就能抗住一个中小型公司的连接数；...

一、单机版1、在本地进程中进行统计，使用常用限流方式2、Nginx中限流，使用lua脚本统计经过该Nginx的实例和接口量二、集群版A、B、C三个服务端节点组成集群，需要将某个接口限制TPS最大为1万；使用一个统计监控服务节点（主备方式做高可用），A、B、C三个节点每秒向统计节点发送每次统计结果数据：请求量、正确处理量、每次请求耗时等；统计监控服务节点每分钟统计一次，...

简介Zipkin是Twitter开源的调用链分析工具，目前基于springcloud sleuth得到了广泛的使用，特点是轻量，使用部署简单。Pinpoint是韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入。SkyWalking是本土开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能较强，...

作为 NewSQL 数据库，TiDB 兼顾了传统关系型数据库的优秀特性以及 NoSQL 数据库可扩展性，以及跨数据中心（下文简称“中心”）场景下的高可用。本文档旨在介绍跨数据中心部署的不同解决方案。三中心部署方案TiDB, TiKV, PD 分别分布在 3 个不同的中心，这是最常规，可用性最高的方案。优点所有数据的副本分布在三个数据中心，任何一个数据中心失效后，另外两个数据中心...

一、垂直拆分1、根据业务不同拆分成多个es集群：比如日志集群、binglog集群、业务数据集群等2、根据系统等级不同拆分不同配置的es集群3、统一封装数据平台层，数据插入和查询使用统一的封装平台，避免过多系统连接es集群，同时避免写入量过大拖垮集群4、冷热数据分离5、数据统一从kafka进入，避免进入量较大，消费方瓶颈二、查询优化这个问题说白了，就是看你有没...

一、熔断的目的系统微服务化后，分布式部署，系统之间通过RPC框架进行通信，系统发生故障的概率随着系统规模的增长而加大；在调用服务时，一些非关键路径发生问题，不能影响整个系统的服务。二、熔断系统需求1、熔断返回默认值，或者null，最好RPC client就能支持，无需业务改动；2、熔断发生时，进行报警，并打印异常日志；3、可以实时下发配置，手动和自动都可以实现熔断；...

一、下面方式有什么问题？try{ 1、插入数据库 2、发送消息到MQ（超时情况） 3、提交数据库插入}catch(){ 回滚插入数据库}问题：1：成功；2：超时当发送MQ超时时，并不代表就是发送失败了，有可能发送成功了，response时超时，此时回滚，导致数据不一致！二、分布式事物类别：1、刚性分布式事物：强一致性，CAP中的CP模...

一、基于redis分布式锁设计1、实现方式：setnx key value expire time2、存在问题： a、单实例：高可用不能满足 b、主从：主加锁后，尚未同步到从，主宕机，锁不存在，会出现重复加锁问题3、官方建议：使用redlock算法来保证，利用多数成功才算加锁成功，需要至少三个redis主从实例来实现，成本较高。问题本质：分布式锁要求CP...

一、选型：注册中心作为一个服务注册和发现的服务，必须是高可用的，所以应该是AP模型；作为CP模型的zk和etcd，在小规模应用情况下低于千级服务，可以使用，不过跨机房时容易因为网络问题导致注册服务不可用，另外CP模型都是一主多从（选主）情况，写入操作只能通过主节点，所以如果服务过多，服务的心跳检查机制是一个比较频繁的动作，会导致主写入瓶颈；由于zk采用zab协议、etcd采用raft协议进...

一、负载均衡系统1、硬件：F5、A10、Radware2、软件：LVS 4层、Nginx 7层、HAProxy 4层或7层二、负载均衡算法1、随机2、轮询3、加权4、一致性hash：相同的请求参数总是请求同一个服务提供者三、案例：服务发现1、自动发现：zk、etck、consul2、故障自动摘除：服务熔断机制 Hystrix3、请求自动重试...

一、无状态化1、冗余部署多个服务，完全对等2、请求到任一服务，结果都一样3、服务不存储业务上下文信息二、目的弹性扩容、缩容服务三、案例用户session数据，存储在redis集群中，业务系统不存储session数据...

一、性能吞吐量：增加并发数来提高吞吐量响应延迟：缩短响应时间二、分布式系统微服务化三、分库分表或TIDB，读写分离四、无状态化水平扩展五、调用链路分析，热点数据和静态数据尽量靠近用户六、多级缓存、分布式缓存七、容量规划、限流、降级、熔断...

一、负载均衡二、服务无状态化三、update可异步化四、缓存、数据冗余、分布式五、限流、降级、熔断六、服务监控七、服务分级