网站账户上的余额分录怎么做,wordpress老版本号,做网站过程中的自身不足,wordpress 限时 插件高并发写优化理论
对于高并发的读QPS优化手段较多#xff0c;最经济简单的方式是上缓存。但是对于高并发写TPS该如何提升#xff1f;业界常用的有分库分表、异步写入等技术手段。但是分库分表对于业务的改造十分巨大#xff0c;涉及迁移数据的麻烦工作#xff0c;不会作为…高并发写优化理论
对于高并发的读QPS优化手段较多最经济简单的方式是上缓存。但是对于高并发写TPS该如何提升业界常用的有分库分表、异步写入等技术手段。但是分库分表对于业务的改造十分巨大涉及迁移数据的麻烦工作不会作为常用的优化手段。异步写入到时经常在实际工作中使用但是也不适合所有场景特别对于带有事务的写入请求带事务的写入请求通常是需要同步告知用户处理结果所以不适用异步处理。
我们都知道批处理会比单条处理快很多只需要发起一次网络请求在网络层面节省了N次TCP连接获取和发送数据的步骤。实际我测试过通过shark抓包发现建立一条TCP连接可能需要耗费10ms~50ms左右。如果是跨洲际的TCP连接更久可能耗费几百毫秒。单是节省的多次TCP连接就能节省不少时间其次还有程序代码的循环执行时间。所以将多个写请求聚合成一个合适大小的批量写请求一次性将数据发送给服务器进行批量写入是最高效的。
MySQL的组提交原理
在MySQL层面为了保证事务的可靠性和数据同步给备节点、从节点的可靠性。通常会开启双一设置。在双一设置开启后就会在事务提交前将redo log、binlog落盘事务才返回成功这就是WAL机制。 sync_binlog1 innodb_flush_log_at_trx_commit1 我们知道由于WAL机制写入请求在修改了数据页后不会立即刷回磁盘而是通过记录rodo log和binlog保证事务的持久性和同步给从节点。写rodo log和binlog就是顺序写入的涉及磁盘的顺序写机制。磁盘顺序写会比随机写快很多。MySQL为了进一步提升多个事务在高并发下写入binlog的性能采用了“组提交”的概念。顾名思义就是将多个事务在单位时间内聚集起来一起写入磁盘就变成了多事务的批量顺序写入性能高很多。
这里简单介绍组提交。首先MySQL有2个参数控制组提交的等待时间和组大小。 binlog_group_commit_sync_delayN在等待N μs后开始事务刷盘(图中Sync binlog) binlog_group_commit_sync_no_delay_countN如果队列中的事务数达到N个就忽视binlog_group_commit_sync_delay的设置直接开始刷盘 解释下这张图。首先在第一步就已经将redo log刷到磁盘了接下来就是将多个事务聚合在一个组调用write函数写入OS的缓冲。第一个到达的事务就会开启一个新组等待N个事务到达或者等待N微秒之后主动提交。假设事务T1到达并开启新组1等待T2来到加入组1等待时间满后T1主动调用write函数将T1、T2事务都写入OS缓冲。此时T1、T2组成的组1进入第二个阶段准备调用flush函数将缓冲区的数据刷入磁盘。组1在第二阶段继续等待新事务加入此时有新组到达就会将组2和组1合并新组再调用flush函数将组1、组2数据刷入磁盘。整个过程是批量顺序写入磁盘是很高效的。 我的组提交Spring组件 我把这个组提交管理器的组件放到我GitHub上了大家觉得不错的请Star或觉得有优化空间的请提出mr有错误的请斧正。
GitHub-组提交管理器
我们基于以上的理论分析可以得出如果我们在高并发写入的时候能够模仿MySQL的组提交实现一个主动等待和被动唤醒提交的组提交机制将多个写入请求合成一个请求发送给MySQL就能提高写入性能。
总结MySQL的组提交机制原理
第一个到达的线程开启新组作为本组Leader领导本组的数据提交Leader等待指定X毫秒时间时间到后主动发起提交第K个线程到达若发现本组负载满了唤醒Leader进行本组提交组与组之间互不阻塞单位时间内可能有多个组并发提交
基于以上原理我设计了两个类GroupManager组管理器、GroupCommit组提交对象。GroupManager负责接收外部线程提交的数据然后放到当前组里。并且实现整个组提交的流程。GroupCommit是一个组的具象化对象提供一个组的入队提交数据挂起等待唤醒Leader等基础方法给GroupManager调用以实现组提交机制。
为了避免高并发时多线程竞相进入组内导致组错乱使用了两把锁解决。大部分线程都会被挡在第一关每次只会放一个线程进到临界区尝试入组。入组之前要先获得当前组的锁为什么要第二把锁因为Leader会主动醒来提交本组的数据队列所以提交时要确保所有资源都是排他的需要组内锁来保证。入组的线程抢到组内锁之后就代表可以安全入组此时有三种情况
如果此时入组前发现组已经满了就开一个新组自己当Leader并唤醒当前组的Leader让它赶快提交如果入组后发现组满了唤醒当前组Leader让它赶快提交自己则挂起等待提交后唤醒入组后发现还未满挂起自己等待唤醒
线程在获取到组内锁后都会立即释放GroupManager的锁目的是让后续线程如果发现当前组满了就立即开新组提交提高效率。 系统架构 因为我们工作中大多数使用的是Tomcat容器目前Tomcat的IO处理模型是Reactor线程池的模式。 在整个系统架构层面组提交影响性能的有两个参数组大小和等待时间。组大小就是在组内挂起等待的线程数等待时间是Leader主动等待的毫秒数。组大小直接影响到剩余可工作的线程数Tomcat线程数量默认200通常我们根据业务场景和硬件资源调整线程数量也就几百左右。如果组大小太大同时等待时间太久直接把Tomcat所有线程都挂起了这时服务器就假死了所以对组大小的设置建议通过压测来确定按照下面的压测经验一般建议设置为Tomcat线程数量的1/4~1/2。这样最大1/2能确保还有一半线程可以服务其它请求。
等待时间因为这个参数会导致接口RT上升建议设置在5ms~20ms之间。我们生产MySQL的组提交等待时间设置500微秒是很短的。我经过反复压测和调参发现纯MySQL插入操作等待时间5ms左右就合适了。
总结起来组大小和等待时间需要根据业务类型和Tomcat线程数量和CPU数量经过测试来决定一个合适的参数没有通用的方法论能决定。
在整个系统架构层面负载均衡器和服务器PodTomcat线程池和多个组提交的关系。 压测报告
环境介绍
Mac OS M2 10核16GSSDMySQL 8.0JDK8u221SpringBootTomcat线程池400Druid数据库连接池 40连接数Jmeter 5.3700线程并发循环1000共70万请求JVM参数设置 -XX:-ClassUnloadingWithConcurrentMark -Xms4g -Xmx4g -Xmn3g -XX:G1HeapRegionSize4m -XX:InitiatingHeapOccupancyPercent30 -XX:MaxGCPauseMillis200 -XX:MaxMetaspaceSize268435456 -XX:MetaspaceSize268435456 -XX:ParallelGCThreads10 -XX:ParallelRefProcEnabled -XX:-ReduceInitialCardMarks -XX:UseCompressedClassPointers -XX:UseCompressedOops -XX:UseG1GC MySQL没有经过调优都是默认的参数。MySQL和应用服务还有Jmeter都是在Mac上运行的。对比两种测试用例1.使用组提交组件 2.单条数据写入。 PostMapping(/submit)public Boolean submit() {long tid Thread.currentThread().getId();log.info(threadId{}, tid);OrderInfo orderInfo new OrderInfo();orderInfo.setOrderNo(UUID.randomUUID().toString());orderInfo.setAddressId(123321123321123L);orderInfo.setMerchantId(123321123321123L);orderInfo.setUserId(123321123321123L);orderInfo.setOrderAmount(BigDecimal.valueOf(123123L));return groupManager.queueGroup(orderInfo);}PostMapping(/submit2)public Boolean submit2() {OrderInfo orderInfo new OrderInfo();orderInfo.setOrderNo(UUID.randomUUID().toString());orderInfo.setAddressId(123321123321123L);orderInfo.setMerchantId(123321123321123L);orderInfo.setUserId(123321123321123L);orderInfo.setOrderAmount(BigDecimal.valueOf(123123L));return orderInfoService.save(orderInfo);}
经过反复实验以及调整组提交的组大小、等待时间参数得出组大小200等待时间5ms得出的TPS是比较好的。TPS达到近8800。接口错误率几乎没有 单提交每次请求提交一次所有配置和环境一致的情况下。并发700循环1000次70万请求。TPS在5200。错误率0 可以看出组提交比单提交TPS高出68%左右优化比较明显。如果能针对组大小和等待时间继续调整优化可能TPS会更高。RT上平均时间比但提交快了1倍但是P99、P95、P90都比单提交要慢1倍。
