（源码阅读先看主线 再看支线 先点到为止 后面再详细分解）
高可用的设计就是：当producer发送消息到broker上，broker却宕机，那下一次发送如何避免发送到这个broker上，就是采用LatencyFaultLorent，记录失败/高延迟的broker信息
MQClientInstanc
start()
- MQClientAPIInstance
- 定时任务：每隔30s去namesrc更新topicrouteinfo（因为它不能实时得知broker有没有挂掉）
- 定时任务：每隔2分钟去获取namesrv
- 心跳：定时向broker 发送心跳信息
- 定时任务：持久化消费进度
- 定时任务：动态调整线程池（探究是不是好的实践）
- 开启拉消息的线程
- 开启队列负载线程
producer
send()
超时时间默认3s，发送方式sync，async（发完就走，有回调），oneway（不关注是否成功回调）
- 尝试获取topic路由信息：从producer缓存好（是由定时拉取namesrv得到的）的路由信息中获取，如果为空，就主动从namesrv更新路由信息
- 选择一个消息队列发送，然后判断队列是否可用latencyFaultTolerance.isAvailable(根据发送到broker延迟时间决定)，如果不可用就下移一个队列
- 开启高可用
- 不开启：对队列轮询
- sendKernel：区分发送模式
- sync
- async
- oneway