这篇文章主要介绍“transfer服务并发优化的方法是什么”，在日常操作中，相信很多人在transfer服务并发优化的方法是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”transfer服务并发优化的方法是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
在洪雅等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供成都做网站、成都网站制作、成都外贸网站建设 网站设计制作按需定制网站,公司网站建设,企业网站建设,品牌网站设计,成都全网营销,成都外贸网站建设,洪雅网站建设费用合理。
业务反馈Java的Transfer服务有调用超时情况。
阅读代码发现，数据来了之后，循环处理，消息放到本地队列，是同步的方式，这里并发肯定会影响性能，果断优化；
尤其是网络IO，尤其是在for循环中使用网络IO，如果必须要使用，考虑使用缓存替代。
案例一：本次调用hbs获取uuid，其实可以从DB获取，只有获取不到的情况才从接口获取；这个调用接口问题也是服务慢的最主要原因，每次请求如果list的size是1000，且不带uuid，那么就要访问1000次接口，怎么快？
案例二：循环中会往kafka投递数据，这个也是网络IO，可能比调用hbs快很多，但是还是网络IO，还是影响性能的，所以后面改成了本地IO，并使用基于乐观锁的ConcurrentLinkedQueue。
业务如果不关心服务响应内容，可考虑将接口修改成异步，这样业务的请求立即返回，服务端需要考虑的就是如何快速处理服务。
如本次优化，异步后最起码可以解决客户端等待问题，避免由于服务端问题影响客户端。
先说下优化之后的逻辑（分四段处理），每一段一个线程池，每个线程池用不同的名称，方便观察：
--》接收请求，多线程异步处理
--》循环中往ConcurrentLinkedQueue添加数据的时候，采用多线程异步（虽然乐观锁，但是也会碰到自旋情况）
--》新增个定时任务，一秒钟一次消费ConcurrentLinkedQueue的数据，并将数据放到list
--》多线程处理，当list达到200时，push到kafka
然后对每一段的线程池的缓冲队列增加监控，观察哪一步有积压，说明那一步可能比较慢，可以适当增加线程的数量。
本地缓存
优点：速度快，不需要经过建立远程连接，网络传输过程等消耗；
缺点：占用本地内存，当系统处理速度慢的时候，造成本地数据积压，从而消耗本地内存，导致频繁的GC
第三方缓存
优点：不占用本地缓存
缺点：速度慢，需要经过建立远程连接，网络传输过程等消耗；
本系统采集两种方式结合：在offer数据的时候使用本地ConcurrentLinkedQueue存储，消费ConcurrentLinkedQueue数据投递到平台服务端的时候使用kafka进行缓冲，使用flink进行消费kafka数据发送到平台服务端。
为什么这么做呢？
1、在offer数据的时候使用本地ConcurrentLinkedQueue存储，主要考虑这种数据消费起来比较快，不会造成本地积压；
2、投递到平台服务，由于是要建立http连接，有可能受到此服务稳定性的影响，所以为了保障本服务的稳定性，使用flink做这个事情。
合理申请相关配置咨询，提高并发能力。
本服务是两种操作都有，如循环遍历的时候是计算密集型；
将数据推送到远端是网络IO密集型，如果放到一个服务，尤其是一个线程逻辑的时候很容易造成等待，所以此处需要分离，然后对于计算密集型的，申请cpu性能好的，对于IO密集型的选择磁盘或者网卡好的
计算机的并发瓶颈怎么估算？
对于一个2GHZ的CPU，运输速度是20亿次/秒，意味着如果是纯CPU密集型操作，对于简单的请求，理论上能达到20亿次并发，当然这当然是不可能的，因为网络请求还有很多因素的影响，如线程切换消耗，网络IO开销，连接建立过程等，仅供评估使用。
到此，关于“transfer服务并发优化的方法是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！
