深度优先搜索算法（Depth-First-Search），是搜索算法的一种。它沿着树的深度遍历树的节点，尽可能深的搜索树的分支。当节点v的所有边都己被探寻过，搜索将回溯到发现节点v的那条边的起始节点。这一过程一直进行到已发现从源节点可达的所有节点为止。如果还存在未被发 现的节点，则选择其中一个作为源节点并重复以上过程，整个进程反复进行直到所有节点都被访问为止。
深度优先搜索是图论中的经典算法，利用深度优先搜索算法可以产生目标图的相应拓扑排序表，利用拓扑排序表可以方便的解决很多相关的图论问题，如最大路径问题等等。一般用堆数据结构来辅助实现DFS算法。
深度优先遍历图算法步骤：
- 访问顶点v；
- 依次从v的未被访问的邻接点出发，对图进行深度优先遍历；直至图中和v有路径相通的顶点都被访问；
- 若此时图中尚有顶点未被访问，则从一个未被访问的顶点出发，重新进行深度优先遍历，直到图中所有顶点均被访问过为止。
根据《Java虚拟机规范(Java SE 7版)》规定，Java虚拟机内存结构可划分为以下区域：
程序计数器：
虚拟机栈：
本地方法栈：
堆：
方法区：
由于项目需求要把整个线上产品迁移上云，从自建IDC机房的所有服务都迁移至腾讯云。原先考虑采用腾讯云的DTS服务,但是发现他们产品属于公测阶段，在加上腾讯云RDS服务居然没有提供外网访问的tls安全传输保证，这样如果一旦开启外网地址，可能导致数据库被入侵或者攻击。基于以上考虑点，在加上我们同机房数据迁移采用otter的定制版，最终我们决定改造otter，支持跨机房安全传输。otter的改造点详细请查看文章
说明：
说明：
最近我们在性能压测seata Tcc模式中发现了一些问题，seata issue：
业务方tps稳定在200tps左右，但是实际去除seata依赖，tps达到了2000左右；
性能长时间压测几个小时之后，发现tm端出现了rpc 30s超时问题，导致所有的请求都超时，业务无法响应；
seata性能压测
TM端报错
1 | 2020-01-16 19:00:19.956 ERROR 19765 --- [o-8873-exec-288] i.s.core.rpc.netty.AbstractRpcRemoting : wait response error:cost 30000 ms,ip:192.168.202.137:8091,request:timeout=60000,transactionName=test(javax.servlet.http.HttpServletRequest, com.fly.seata.dto.OrderDTO) |
线程栈信息
1 | "ServerHandlerThread_1_500" #86 daemon prio=5 os_prio=0 tid=0x00007fe594011800 nid=0x6138 waiting on condition [0x00007fe6507c0000] |
出现超时之后，server端和Tm端、Rm端有建立连接的
1 | pangpeijie@mdw1:/home/dxy/seata-server/bin$ lsof -i:8091 |
1 | pangpeijie@mdw2:~$ netstat -ano|grep "192.168.202.137:8091" |
其他报错信息请查看github的issue
最近我们生产上的消息推送服务不断的爆出内存增长过大导致操作系统kill该进程，并且随着业务量的增长出现的频次越来越高，由去年12月底的半个月出现一次，到现在的一天出现一次。
该服务的业务逻辑就是消息推送，业务方推送消息，服务方通过rocketmq做削峰处理（之前使用kafka来左右消息队列没出现过问题），其中主要通道是个推和apns（使用pushy框架）通道，业务方的全局推送大概在5000w用户左右，每全局推送一次，内存就会增长几百mb，直到jvm进程内存达到5g之后，系统就会出现服务请求没响应或者被守护进程重启等问题。
刚开始的快速解决方案也只能重启，虽然重启能解决问题，但是也没找到根本原因！
由于我们jvm堆内的初始内存和最大内存都是配置成2g ,但是进程的内存达到5g，那就是说堆外占了3g
-Xms2048m -Xmx2048m
下面是运维监控平台的cpu、内存、线程资源数据，内存在一直在增长，没有回收释放。
出问题的时候监控应用fullgc情况
监控jvm虚拟机的线程增长情况
在使用Spring源码Debug的过程中，遇到了一些问题，如下：
问题1. cannot find symbol CoroutinesUtils
1 | Error:(347, 51) java: cannot find symbol |
问题2. 找不到符号符号: 类 AnnotationTransactionAspect位置: 类 org.springframework.transaction.aspectj.AspectJTransactionManagementConfiguration
问题3. Unexpected AOP exception; nested exception is java.lang.IllegalStateException: Unable to load cache item
1 | Caused by: org.springframework.aop.framework.AopConfigException: Unexpected AOP exception; nested exception is java.lang.IllegalStateException: Unable to load cache item |
1.1 报错日志
1
Could not find first log file name in binary log index file
1.2 现象
pipeline的mainstem状态 一直处于定位中状态
1.3 问题排查
一般出现这个报错，都是由于清空数据库binlog文件导致（自动清除biglog），我们按下述步骤确定是否由于binlog文件被清理：
首先，查看当前同步的binlog位点;
其次，登录数据库查看binlog信息（show master logs）；
最后，对比位点信息就能发现biglog丢失；
1.4 处理方法
1）通道停止增量同步；
2）清空掉otter的同步信息；
3）检查canal的同步位点信息；
4）重新启动otter同步；
2.1 报错日志
无报错日志
2.2 现象
channel状态正常，mainstrm状态正常，但是position信息里，position的信息一直不更新（超过半小时以上）
2.3 问题排查
确认是否为大事物的方法
1）查询数据库当前位点信息（show master logs）；
2）查询位点的详细信息（show binlog events in 'binlog名称'）；
3）查看binlog日志中begin和commit的偏移量相差多大即可；
2.4 处理方法
1）清空掉otter同步信息；
2）检查canal的同步位点配置；
3）重新启动otter同步；
3.1 报错日志
1
java.lang.OutOfMemoryError: unable to create new native thread
3.2 现象
node节点均为运行状态，但是涉及到问题node的channel同步处于挂起状态，且无法解挂及停止；
3.3问题排查
1）根据报错log找到对应的node节点；
2）查看该node节点的日志找到该报错日志；
3.4处理方法
1）重启node节点；
数据迁移核心思路抽象起来其实很简单，但如何稳定平滑迁移数据，我们会遇到不少问题，如：
开源数据同步中间件主要包括canal、otter、maxwell、kettle等，下面进行简单比对说明。
最终结合公司需求，otter功能最强大，二次开发比较方便，最终选择用otter来作为数据同步工具。
全量迁移：数据迁移首要目标如何将历史全量数据迁移到新库中，我们利用otter的自由门原理改造支持全量数据同步功能，整个过程都是查询在线库的备库，因此不影响在线业务的数据库服务，自由门原理如下：
a. 基于otter系统表retl_buffer，插入特定的数据，包含需要同步的表名，pk信息。
b. otter系统感知后会根据表名和pk提取对应的数据(整行记录)，和正常的增量同步一起同步到目标库。
增量迁移：通过模拟mysql slave获取binlog数据，然后通过canal解析增量数据，最终准实时同步数据。
方案一：先开启全量任务，等全量数据同步完成后，在开启增量任务。由于迁移过程中业务服务一直运行，因此全量迁移完全成，并且要将全量时间点后的数据追回来，这里核心原理是同步全量时间位点后binlog日志数据来保证数据一致性，需要注意的是增量时间需要前移一小断时间(如5分钟)，其主要原因是全量迁移启动的那刻会有时间差，需要增量前移来保证数据最终一致性。
方案二：先开启增量任务，然后开启全量任务，这种方案存在当全量和增量任务同时操作同一条pk数据的时候，就可能会产生丢失更新。推荐使用该方案，操作比较简单，这种场景出现的问题是很小的概率，最终还能通过数据校验服务来找到问题数据，然后用一键修复功能即可。
增量同步原理如下：
a. 基于Canal获取数据库增量日志数据。
b. 利用SETL调度模型实现调度和处理实现。
c. 基于zookeeper，解决分布式状态调度的，允许多node节点之间协同工作。
工作原理如下：
反向同步：迁移到新库后，为了保证业务方出现业务回滚，保证源库与目标库数据一致性，需要建立从新库到老库的回流任务，原理跟增量迁移一样，只是变更一下原库及目标库。
一致性校验：通过比对源库和目标库的所有同步字段的crc校验码，如果出现不一致，重新比对3次，如果最终数据不一致，则会将该条数据落库。流程图如下：
一键修复：将一致性校验比对失败的数据，通过全量同步原理来触发数据修复功能。
Otter的业务域是支持异构数据库实时同步，数据记录变更订阅服务。
Otter需要保障数据库的事务一致性，包括DDL（表结构变更）也可以进行同步或过滤。而DBA天生就在这个坑里，绝对不能让主备不一致、或事务不完整，哪怕只是一条数据。而且DBA迫切希望以后不用通知下游了，让DRC自动适配主备切换或拆库。
定位：基于数据库增量日志解析，准实时同步到本机房或异地机房的mysql/oracle数据库.一个分布式数据库同步系统.
Otter具备的三大特性：
我们公司对Otter的需求场景：
数据同步过程可以分为Select–>Extract、Transform–>Load四个过程，也就是上图中的S、E、T、L，通过将这4个步骤进行服务拆分，每个服务都具有自己的线程池。通过S、L过程的串型，保证数据的一致性，E、T过程的并行提升系统处理的性能。
基于Canal开源产品，获取数据库增量日志数据。
典型管理系统架构，manager(web管理)+node(工作节点)
a. manager运行时推送同步配置到node节点;
b. node节点将同步状态反馈到manager上;
基于zookeeper，解决分布式状态调度的，允许多node节点之间协同工作.