前言 秒杀架构持续优化中,基于自身认知不足之处在所难免,也请大家指正,共同进步.文章标题来自码友 简介 LMAX Disruptor是一个高性能的线程间消息库.它源于LMAX对并发性,性能和非阻塞算法的研究,如今构成了Exchange基础架构的核心部分. Disruptor它是一个开源的并发框架,并获得2011 Duke's 程序框架创新奖,能够在无锁的情况下实现网络的Queue并发操作. Disruptor是一个高性能的异步处理框架,或者可以认为是最快的消息框架(轻量的JMS),也可以认为是一

需要的pom文件: <!-- 顺序UUID --> <dependency> <groupId>com.fasterxml.uuid</groupId> <artifactId>java-uuid-generator</artifactId> <version>3.1.4</version> </dependency> 有时间顺序: import com.fasterxml.uuid.Etherne

原文地址:http://maoyidao.iteye.com/blog/1663193 一个仅仅部署在4台服务器上的服务,每秒向Database写入数据超过100万行数据,每分钟产生超过1G的数据.而每台服务器(8核12G)上CPU占用不到100%,load不超过5.这是怎么做到呢?下面将给你描述这个架构,它的核心是一个高效缓冲区设计,我们对它的要求是: 1,该缓存区要尽量简单 2,尽量避免生产者线程和消费者线程锁 3,尽量避免大量GC 缓冲 vs 性能瓶颈 提高硬盘写入IO的银弹无疑是批量顺序

前言碎语 楼主之前推荐过2pc的分布式事务框架LCN.今天来详细聊聊TCC事务协议. 2pc实现:https://github.com/codingapi/tx-lcn tcc实现:https://github.com/yu199195/hmily 首先我们了解下什么是tcc,如下图 tcc分布式事务协议控制整体业务事务分为三个阶段. try:执行业务逻辑 confirm:确定业务逻辑执行无误后,确定业务逻辑执行完成 cancel:假如try阶段有问题,执行cancel阶段逻辑,取消try阶段的

今天用一个停车场问题来加深对Disruptor的理解.一个有关汽车进入停车场的问题.当汽车进入停车场时,系统首先会记录汽车信息.同时也会发送消息到其他系统处理相关业务,最后发送短信通知车主收费开始.看了很多文章,里面的代码都是大同小异的,可能代码真的是很经典.以下代码也是来源网络,只是自己手动敲的,加了一些注释.   代码包含以下内容: 1) 事件对象Event 2)三个消费者Handler 3)一个生产者Processer 4)执行Main方法 Event类:汽车信息   public cla

一个仅仅部署在4台服务器上的服务,每秒向Database写入数据超过100万行数据,每分钟产生超过1G的数据.而每台服务器(8核12G)上CPU占用不到100%,load不超过5.这是怎么做到呢?下面将给你描述这个架构,它的核心是一个高效缓冲区设计,我们对它的要求是: 1,该缓存区要尽量简单 2,尽量避免生产者线程和消费者线程锁 3,尽量避免大量GC 缓冲 vs 性能瓶颈 提高硬盘写入IO的银弹无疑是批量顺序写,无论是在业界流行的分布式文件系统或数据,HBase,GFS和HDFS,还是以磁盘文件

背景 Disruptor是英国外汇交易公司LMAX开发的一个高性能队列,研发的初衷是解决内存队列的延迟问题(在性能测试中发现竟然与I/O操作处于同样的数量级).基于Disruptor开发的系统单线程能支撑每秒600万订单,2010年在QCon演讲后,获得了业界关注.2011年,企业应用软件专家Martin Fowler专门撰写长文介绍.同年它还获得了Oracle官方的Duke大奖. 目前,包括Apache Storm.Camel.Log4j 2在内的很多知名项目都应用了Disruptor以获取高

Hmily框架特性 无缝集成Spring,Spring boot start. 无缝集成Dubbo,SpringCloud,Motan等rpc框架. 多种事务日志的存储方式(redis,mongdb,mysql等). 多种不同日志序列化方式(Kryo,protostuff,hession). 事务自动恢复. 支持内嵌事务的依赖传递. 代码零侵入,配置简单灵活. Hmily为什么这么高性能? 1.采用disruptor进行事务日志的异步读写(disruptor是一个无锁,无GC的并发编程框架) p

什么是 Binlog MySQL Server 有四种类型的日志——Error Log.General Query Log.Binary Log 和 Slow Query Log. 第一个是错误日志,记录 mysqld 的一些错误.第二个是一般查询日志,记录 mysqld 正在做的事情,比如客户端的连接和断开.来自客户端每条 Sql Statement 记录信息:如果你想准确知道客户端到底传了什么瞎 [哔哔] 玩意儿给服务端,这个日志就非常管用了,不过它非常影响性能.第四个是慢查询日志,记录一些

系列译文: http://ifeve.com/disruptor/ 当有多个消费者时,(按Disruptor的设计)每个消费者各自控制自己的指针,依次读取每个Slot(也就是每个消费者都会读取到所有的产品),这时只需要保证生产者指针不会超过最慢的消费者(超过最后一个消费者“一圈”)即可,也不需要锁. 重复消费http://blog.csdn.net/zero__007/article/details/49684363 Disruptor多个消费者不重复处理生产者发送的消息的demo Disrup

4. 分布式事务解决方案之TCC 4.1. 什么是TCC事务 TCC是Try.Confirm.Cancel三个词语的缩写,TCC要求每个分支事务实现三个操作 :预处理Try.确认Confirm.撤销Cancel.Try操作做业务检查及资源预留,Confirm做业务确认操作,Cancel实现一个与Try相反的操作既回滚操作.TM首先发起所有的分支事务的try操作,任何一个分支事务的try操作执行失败,TM将会发起所有分支事务的Cancel操作,若try操作全部成功,TM将会发起所有分支事务的Con

这书以分布式微服务系统为主线,讲解了微服务架构设计.分布式一致性.性能优化等内容,并介绍了与微服务系统紧密联系的日志系统.全局调用链.容器化等. 还是一样,每一章摘抄一些自己觉得有用的内容,归纳整理,然后加以理解. 第1章 分布式微服务架构设计原理 1. 由传统单体架构到服务化架构 (老生常谈,感觉所有谈到微服务的内容都是从这个角度开始叙述.) (1)J2EE是二八原则的典型应用场景:它将80%通用的与业务无关的逻辑和流程封装在应用服务器的模块化组件里,通过配置的模式提供给应用程序访问,应用程序

分布式事务解决方案之TCC 4.1.什么是TCC事务 TCC是Try.Confirm.Cancel三个词语的缩写,TCC要求每个分支事务实现三个操作:预处理Try.确认Confirm.撤销Cancel.Try操作做业务检查及资源预留,Confirm做业务确认操作,Cancel实现一个与Try相反的操作即回滚操作.TM首先发起所有的分支事务的try操作,任何一个分支事务的try操作执行失败,TM将会发起所有分支事务的Cancel操作,若try操作全部成功,TM将会发起所有分支事务的Confirm操

个人博客网:https://wushaopei.github.io/    (你想要这里多有) 1.什么是TCC事务 TCC是Try.Confifirm.Cancel三个词语的缩写,TCC要求每个分支事务实现三个操作:预处理Try.确认Confifirm.撤销Cancel.Try操作做业务检查及资源预留,Confifirm做业务确认操作,Cancel实现一个与Try相反的操作即回滚操作.TM首先发起所有的分支事务的try操作,任何一个分支事务的try操作执行失败,TM将会发起所有分支事务的Can

一,为什么要给shardingsphere配置多数据源? 1,shardingjdbc默认接管了所有的数据源, 如果我们有多个非分表的库时,则最多只能设置一个为默认数据库, 其他的非分表数据库不能访问 2,shardingjdbc对数据库的访问有一些限制: 官方站的说明: https://shardingsphere.apache.org/document/legacy/4.x/document/cn/manual/sharding-jdbc/unsupported-items/ 说明:刘宏缔的

一,shardingshpere为什么要整合seata? 分库分表是数据库扩展中最常用的处理方法, shardingshpere作为使用最广泛的分表中间件, 如果不支持分布式事务,则它的数据一致性就会打很大的折扣了 shardingsphere实现了对分布式事务seata的支持, 对于数据有高要求的应用来说,当然需要整合seata 说明:刘宏缔的架构森林是一个专注架构的博客,地址:https://www.cnblogs.com/architectforest 对应的源码可以访问这里获取: htt

一,什么是seata? Seata:Simpe Extensible Autonomous Transcaction Architecture, 是阿里中间件开源的分布式事务解决方案. 前身是阿里的Fescar   官方站: http://seata.io/zh-cn/  官方代码地址: https://github.com/seata/seata  官方文档站: http://seata.io/zh-cn/docs/overview/what-is-seata.html 各版本的release

Paxos算法在分布式领域具有非常重要的地位.但是Paxos算法有两个比较明显的缺点:1.难以理解 2.工程实现更难. 网上有很多讲解Paxos算法的文章,但是质量参差不齐.看了很多关于Paxos的资料后发现,学习Paxos最好的资料是论文<Paxos Made Simple>,其次是中.英文版维基百科对Paxos的介绍.本文试图带大家一步步揭开Paxos神秘的面纱. Paxos是什么 Paxos算法是基于消息传递且具有高度容错特性的一致性算法,是目前公认的解决分布式一致性问题最有效的算法之一

关于分布式锁的概念,具体实现方式,直接参阅下面两个帖子,这里就不多介绍了. 分布式锁的多种实现方式 分布式锁总结 对于分布式锁的几种实现方式的优劣,这里再列举下 1. 数据库实现方式 优点:易理解 缺点:操作数据库消耗较大,性能较低.为了处理一些异常,会使得整个方案越来越复杂 2. 缓存实现方式 优点:性能好,实现起来较为方便. 缺点:通过超时时间来控制锁的失效时间并不是十分的靠谱. 3 zookeeper实现 优点:有效的解决单点问题,不可重入问题,非阻塞问题以及锁无法释放的问题. 缺点:性能

前言:       由于在平时的工作中,线上服务器是分布式多台部署的,经常会面临解决分布式场景下数据一致性的问题,那么就要利用分布式锁来解决这些问题.所以自己结合实际工作中的一些经验和网上看到的一些资料,做一个讲解和总结.希望这篇文章可以方便自己以后查阅,同时要是能帮助到他人那也是很好的. ===============================================================长长的分割线===================================