生产者和消费者模式
- 通过平衡生产线程和消费线程的工作能力来提高程序整体处理数据的速度，解决生产消费能力不均衡的问题
- 生产者和消费者通过阻塞队列来通信，解耦生产者和消费者
生产者消费者模式实战
需求：申请一个专门用来收集分享邮件的邮箱，分享文章发送到这个邮箱，将邮箱地址放在部门邮件列表里，分享人只需向整个部门分享，工具读取邮件服务器里该邮箱的邮件，把分享邮件下载，要求分享的邮件标题必须带关键字，把文件插入到confluence里，工具还可以把文章进行 分类和归档
单线程处理流程（每5分钟抽取一次）：抽取邮件----添加文章-----清空邮件
消费者生产者模式：
- 生产者线程按一定规则去邮件系统抽取邮件
- 存放在阻塞队列
- 消费者从阻塞队列里取出文章后插入到confluence里
多生产者和多消费者场景
- 生产者1负责将所有客户端发送的消息存放在阻塞队列1里
- 消费者1从队列读消息，通过消息id进行散列得到N个队列中的一个
- 根据编号将消息存放到不同队列，每个阻塞队列会分配一个线程来消费阻塞队列里的数据，
- 如果消费者2无法消费消息，就将消息再抛回到阻塞队列1中，交给其他消费者处理
线程池与生产消费者模式
线程池就是一种生产者和消费者模式的实现方式，生产者把任务丢给线程池，线程池创建线程并处理任务，如果将要运行的任务数大于线程池的基本线程数就把任务扔到阻塞队里。
线上问题定位
- linux命令 top查看每个进程情况
- 使用top 的交互命令数字1查看每个cpu性能数据
- 使用top的交互命令H查看每个线程的性能信息
- 某个线程cpu利用率一直是100%，说明这个线程可能死循环
- 某个线程一直在top10位置，说明这个线程可能有性能问题
- cpu利用率高的几个线程在不停变化，说明并不是由某个线程导致cpu偏高
- 第一种情况也有可能是GC造成的，jstat命令查看gc情况，看是不是持久代或老年代满了，产生了FullGC,导致CPU利用率持续飙高
- 可以把线程dump下来，看那个线程的代码造成的（dump的线程id是十六进制的，top命令的线程是十进制的）
性能测试
-
假设要支持2万QPS（峰值，不是平均值），单机支持1千QPS，需要20台机器才能支持
-
实现：java程序用线程池调度任务，10台机器上部署，每台100个线程，压测半小时
-
结果：QPS达到1400，程序开始报错获取不到数据库连接，用netstat命令查看已经使用了多少个数据库连接
-
改进：数据库连接增加到20，QPS每行去，响应时长从平均1000毫秒下降到700毫秒
- 使用top查看，
- 升级CPU 2核变4核，和线上的机器保持一致，再压测，cpu75%，QPS上升到1800
- 增加应用服务器里线程池的核心线程数和最大线程数到1024，通过ps命令查看线程数是否增长
- 再次压测QPS无明显增长，单机稳定在1800，响应时长稳定在200毫秒
-
命令总结：
- 查询有多少台机器连接到这个端口：netstat -nat | grep 12200 -c
- 查看使用了多少个数据库连接：netstat -nat | grep 3306 -c
- 查看线程数是否增长 ps -elf | grep java -c
- 查看网络流量cat /proc/net/dev
- 查看系统平均负载：cat /proc/loadavg
- 查看系统内存情况 cat /proc/meminfo
- 查看cpu利用率 cat /proc/stat
异步线程池
- 如果一个任务扔进线程池后，运行线程池的程序重启了，那么线程池里的任务就丢失了，线程池只能处理本机的任务，在集群环境下不能有效地调度所有机器的任务，需要结合线程池开发一个异步任务处理池
- 任务池处理流程：
- 每台机器会启动一个任务池，每个任务池里有多个线程池
- 当某台机器将一个任务交给任务池后，任务池会先将这个任务保存到数据库中
- 某台机器上任务池会从数据库中获取待执行任务，再执行这个任务。
- 任务状态
- 创建：提交给任务池之后的状态
- 执行中：任务池从数据库中拿到任务执行时的状态
- 重试：当执行任务时出现错误，程序显式地告诉任务池这个任务需要重试，并设置下一次执行时间
- 挂起：当一个任务的执行依赖于其他任务完成时，可以将和这个任务挂起，当收到消息后，再开始执行
- 中止：任务执行失败，让任务池停止执行这个任务，并设置错误消息告诉调用端
- 执行完成：任务执行结束
- 任务池的任务隔离：对任务进行隔离执行，使用不同的线程池处理不同的任务，或者不同的线程池处理不同优先级的任务，如果任务类型非常少，建议用任务类型来隔离，如果任务类型非常多，建议采用优先级的方式隔离
- 任务池的重试策略：根据不同任务类型设置不同的重试策略，有的任务对实时性要求高，每次重试间隔比较短，对实时性要求不高，可以采用默认的重试策略，重试间隔随次数的增加，时间不断延长，每个任务类型可以设置执行该任务类型线程池的最小和最大线程数，最大重试次数
- 使用任务池的注意事项：任务必须无状态，任务不能在执行任务的机器中保存数据，比如某个任务是处理上传的文件，任务的属性里有文件的上传路径，如果文件上传到机器1，机器2获取到了任务则会处理失败，所以上传的文件必须存在其他的集群里，比如oss或sftp
- 异步任务的属性：包括任务名称，下次执行时间，已执行次数，任务类型，任务优先级和执行时的报错信息（用于快速定位问题）