如何用低廉的成本高效提高事务吞吐量

昨天回去仔细又想了下觉得太啰嗦,几句话概括: 利用好缓存提高查询效率,在内存中完成事务,然后写事务日志(此时写完可以返回结果),将一个事务简化为一个写的操作,另外再异步提交数据库,此方法效率提高点在于,内存数据处理非常高效,整个事务只有在写日志时候才涉及磁盘操作.

背景:很多中小公司,在做业务开发的时候,不会考虑tps, 一般只要开发出功能.但是业务增长时候tps是个瓶颈,我们常用关系型数据库,吞吐量实在是小.在一个独立的服务中或者说一个应用中,如何用低廉的成本高效提高tps, 为此我基于已有的经验写的这篇文章.小弟才疏学浅,不对的地方望指正,
思路来源于分布式事务,把一个事务拆分成若干个微小事务,最小为一条语句增删查改. 用磁盘型的nosql来作为存储, 事务控制由应用程序来做,在事务开始和结束的地方用唯一标记控制,标记这个事务执行状态,并存储执行数据的副本,结束时候记录事务提交状态.最后由专门的程序检验事务并同步到关系型数据库(其实就是异步提交思想,只是保证应用中数据是最新的,无法保证关系型数据库中的数据最新,可以保证应用中的数据会最终同步到关系型数据库中), 那么这里会有并发,并发的数据共享怎么做? 读到内存用锁,从这个层面看, 事务就是内存事务,redis已经支持了简单的事务,不同的是这里强调事务完成时候就落地,控制,nosql只是作为落地存储提高效率, nosql还可以通过单独的应用和关系型数据库同步.注意,在事务提交到副本后同步到关系型数据库是注意事务提交顺序,这个可以很容易,比方说事务id是递增,如此一来单机tps吞吐量轻松几千.(数据来源一个简单应用程序的改造,说不定上万都有可能,实际数据是每秒不超过2k的访问,平常也就5百左右,线上单机达到几百的tps,包括应用服务器在内资源占用率不超过10%cpu,一个tps基本上包含若干条查询,和约2-5条插入或是更新).
我来形容下这个方法,这可以称之为”土方法”, 其实现在很多解决方案了,分布式,服务拆分…等等,但是此方法短期对于应对是很有效的,第一他无需大改项目,只是把数据驱动换一下(当然你要封装一下数据事务驱动),第二.他能在短时间内不需要你学习新的技术栈(当然nosql你的会,这不算啥新技术栈吧).第三就是很高的运行效率了.
局限:第一.一旦完做成该模式后,采用该模式后,所有的数据操作必须通过同一个数据驱动应用对数据读写进行,无法并发,否则数据不一致(自己分析的),第二.断电后事务虽然不丢失,但是再次读写前必须等待当前副本中的事务提交完全.(没提交完全时候,会产生数据不一致,自己分析的)
非常适用的场景: 1比方说一个事务里面有很多数据是插入记录行的语句,比方说银行转账需要插入很多记录对于记录这种数据量非常大,但是金钱相关的数据有时候又必须放到关系型数据库中(当然也可以用其他存储,但是别跟我说这些,那是因为你不了解银行系统和传统企业). 2对相同数据大量更新操作,

题外话:至于是什么程序请不要深趴,太丢人,前端bug不断访问后端,当然解决办法是拿有效数据(排除一些时间戳等加密数据),然后md5,将其重复的找出丢弃,只是这个问题产生后就想起怎么解决并发时候事务吞吐量,并拿他实验.另外,应用程序的副本数据需要删除(避免撑爆内存),应该由事务提交的程序通知删除