mysql之innodb自增锁原理实现
mysql之innodb自增锁原理实现 1 自增锁知识点 1.1 定义 自增锁是一种表级锁（table-level lock），专门针对插入 AUTO_INCREMENT 类型的列。同一表，假设事务 A 正在插入数据，则另一个事务 B 尝试 INSERT 语句，事务 B 会被阻塞住，直到事务 A 释放自增锁，以便事务A插入的行是连续的主键 ID
nicky_chin
I can accept failure,but I can't accept not trying
大家好，我叫 陈星，来自杭州。平时喜欢打打球，看看书。 我的人生格言：机会是留给有准备的人的，厚积薄发总归会有收获，沉下心来做事情, 才能一往无前......
mysql之innodb锁系统源码分析
mysql之innodb锁系统源码分析 1 锁系统 在 mysql 中 innodb 是常用的存储引擎，我们经常会遇到慢 sql 或者死锁，所以深入了解 DDL 和 DML 语句下锁机制是非常有必要的。
mysql快照读原理实现
Innodb之快照读原理实现 1 Innodb MVCC组成 1. 1 为何使用MVCC实现快照读 innodb存储引擎的快照读是基于多版本并发控制 MVCC 和 undolog 实现，通过 MVCC 机制提高系统读写并发性能，快照读只发生于 select 操作，但不包括 select … lock in share mode, select … for update 提高并发的思路 并发数据一致性通常实现: 锁 + 多数据版本
java的clone方法JVM实现
例子
class Base { String name; public Base(String name) { this.name = name; } } 构造clone的类
基于TimeLine模型的消息同步机制
正常的IM系统流程
在这个方式下，消息同步的基本思路和步骤如下（序号不对应图中序号）
1、把消息存储到离线收件箱
2、向在线用户推送消息
3、在线用户返回收到消息的ack信息
4、服务端清除用户此条离线消息
对于离线用户，登录后直接拉取离线消息即可
这个消息同步方式有它合理的地方
1、流程比较直观
2、网络交互量较少（相对于后边的TimeLine模型而言）
但是这个方案存在更多不足的地ti方
1、我们有App和Web两个端，需要为每个端都写一份离线消息。由于离线消息是扩散写的，多写一份，服务端就多一份压力 2、消息ack回来之后，服务端需要把对应的消息从存储中删除，这个过程性能也是一个问题 这个消息模式在比较单一的IM应用场景下还是能够胜任的。但是随着消息场景越来越复杂，尤其是SDK推出以后，这个模式就存在很多弊端。SDK的应用可能存在很多个端，服务端不可能为每个端都写离线消息！ 对于SDK，我们采用TimeLine模型来实现客户端和服务端的消息同步。 以下内容是钉钉的做法，比较了传统架构和现代架构。而我们现在的IM消息同步这块介于两者之间。
线程传递增强之TransmittableThreadLocal
先来看TTL里面的几个重要属性及方法
TTL定义：
public class TransmittableThreadLocal extends InheritableThreadLocal 可以看到，TTL继承了ITL，意味着TTL首先具备ITL的功能。
再来看看一个重要属性holder：
/** * 这是一个ITL类型的对象，持有一个全局的WeakMap（weakMap的key是弱引用，同TL一样，也是为了解决内存泄漏的问题），里面存放了TTL对象 * 并且重写了initialValue和childValue方法，尤其是childValue，可以看到在即将异步时父线程的属性是直接作为初始化值赋值给子线程的本地变量对象（TTL）的 */ private static InheritableThreadLocal<Map<TransmittableThreadLocal<?
浅析java-nio及netty的reactor模型
1 服务端处理网络请求 首先看看服务端处理网络请求的典型过程：
由上图可以看到，主要处理步骤包括：
获取请求数据，客户端与服务器建立连接发出请求，服务器接受请求（1-3）。
构建响应，当服务器接收完请求，并在用户空间处理客户端的请求，直到构建响应完成（4）。
返回数据，服务器将已构建好的响应再通过内核空间的网络 I/O 发还给客户端（5-7）。
设计服务端并发模型时，主要有如下两个关键点：
服务器如何管理连接，获取输入数据。
服务器如何处理请求。
2 Reactor 模式 2.
Transaction源码解析之事务提交与回滚
1 事务还原 1.1 调试demo 我们使用常用的业务代码来做调试：
@Service("personService") public class PersonServiceImpl implements IPersonService { @Override @Transactional(propagation = Propagation.
Transaction源码解析之事务预处理
1 调试源码 接上篇Transaction源码解析之事务的配置解析
我们调用相应的service类,来调试具体的事务处理流程，测试代码如下:
public void testInvokeTransactional() throws Exception { TransactionalTestBean testBean = getTestBean(); CallCountingTransactionManager ptm = (CallCountingTransactionManager) context.
Transaction源码解析之事务配置解析
1 事务配置 关于Spring的事务，大家每天都会遇见或者用到，为了更好的理解Transaction的原理机制，我们从源码角度来解析，本文的调试源码基于Spring-3.2.x版本进行调试。
1.1 配置 配置XML文件annotationTransactionNamespaceHandlerTests.xml
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:context="http://www.springframework.org/schema/context" xmlns:tx="http://www.
