前一篇文章主要讲述MySQL的InnoDB存储引擎的基础，特性，优势等，本文主要聚焦于InnoDB的架构设计，对其内部的主要组件作相应介绍。
缓冲区(Buffer Pool)缓冲区是InnoDB用于缓存表和索引数据的一块主内存区，对于频繁访问的数据，可以直接从该缓冲区获取。对于专用的数据库服务器，通常可以分配80%的物理内存用于该缓冲区。为了提升大批量读操作的性能，缓冲区会被分为多个数据页，每页包含了多行记录。为了提升缓存管理的性能，缓冲区由链表页组成；对于很少访问的数据，将基于LRU算法，从缓冲区中清除。关于InnoDB Buffer Pool的细节，可见这里。
更新缓冲区(Change Buffer)更新缓冲区是一种特殊的数据结构。当相关页不在缓冲区里时，更新缓冲区可用于缓存二级索引页的变化。缓冲区的变化可由INSERT，UPDATE，DELETE等DML语句引起，随后当页面被加载进缓冲区后，这些变化将与其他读操作进行合并。
不像聚簇索引，二级索引通常并不是唯一的，并且插入二级索引时，会以相对随机的顺序。类似地，删除或更新操作可能会影响位于索引树不相邻的二级索引页。当相关页被...阅读全文

2016 年 10 月 25 日mysql对于DBA，通常需要对数据库服务器的磁盘I/O作相关监控管理，以免发生I/O资源过于紧张，进而导致服务器不稳定及崩溃。除此之外，磁盘空间管理也很重要，需要为数据库保证足够的磁盘空间。ACID设计模型为了保证数据的可靠性(比如，通过写Undo Log等)，也需要I/O资源。而InnoDB在运行过程中，会尽可能降低I/O操作和优化磁盘文件的组织(如，延迟某些I/O操作直到数据库空闲时，或者为了保证数据一致性，在数据库重启后执行某些恢复操作)。本文将描述InnoDB的磁盘I/O和文件管理的相关细节。
InnoDB的磁盘I/OInnoDB会在可能的情况下使用异步磁盘I/O，主要通过创建多个线程来处理I/O操作，与此同时允许其他数据库操作。 在Linux和Windows平台上，InnoDB使用可用的操作系统和库函数来执行“本地”异步I/O，而在其他平台上，InnoDB仍然使用I/O线程，但实际上线程可能会等待I/O请求完成，这种技术也被称为模拟异步I/O。
预读(Read-Ahead)当InnoDB可以确定如果某些数据将很可能被使用，则会执行预读操作...阅读全文

垃圾收集(GC)中的性能指标延迟时间(Latency)在日常开发中，经常会有这样的需求，要求用户的某个操作，必须在1秒内得到响应，这个时候首先需要确认的是，垃圾收集(GC)造成的暂停时间是否占用得过多，若GC造成的暂停时间仅几十毫秒，则可以尝试从其他层面去作优化处理，比如外部数据源，锁争用等问题，事实证明，这些问题可能会比GC问题出现得更多。假设，现在的性能需求是：90%的操作的响应时间必须小于1000ms，没有任何操作的响应时间大于10000ms，并假设GC停顿占用的时间不能超过10%，即90%的GC暂停时间不能超过100ms，没有一次GC的暂停时间超过1000ms。如下面的GC日志：
[Full GC (Ergonomics) [PSYoungGen: 93677K- >70109K(254976K)] [ParOldGen: 499597K->511230K(761856K)] 593275K->581339K(1016832K), [Metaspace: 2936K->2936K(1056768K)], 0.0713174 secs] [Times: user=0.21 sy...阅读全文

2016 年 03 月 15 日jvm在日常开发中，除了编写程序外，其他比较关注的会有垃圾收集器(GC)相关的问题，在默认的JVM行为下，可能会随着业务量或应用需求，这样的默认行为可能无法满足需求(主要可从吞吐量或系统暂停响应等因素考虑)，对垃圾收集器(GC)的调整，是比较普遍的，当然也可能会针对使用不同的垃圾收集器(GC)时，进一步调整一些JVM参数，如堆大小，分代配额等信息，而能帮助开发人员在调整这些参数前，作一些跟踪判断的重要信息，则是垃圾收集日志。本文将详述相关的一些GC日志细节。
不同的GC收集器组合尽管在Java内存管理基础中，提到了一些常见的垃圾收集器，但在现实应用中，比较常见的组合使用大概就四种：
年轻代和老年代均使用Serial GC。年轻代和老年代均使用Parallel GC。年轻代使用Parallel GC，年轻代使用CMS收集器。不进行年轻代和老年代区分，使用G1收集器。为了触发各类GC组合触发垃圾收集，本文将使用如下代码：
public class GCLogDetailTest {// 1Mprivate static int M_1 = 1024 *...阅读全文

2016 年 01 月 15 日springSpring Web 3.1之后引入了叫作Flash Attribute的功能，旨在解决类似POST/Redirect/GET这种请求模式中的属性传递问题，但由于从老系统到新系统的迁移过程中，用户Session都开始使用基于Redis的会话组件(HttpSession的Redis版本)，在老系统的POST/Redirect/GET这种请求模式下出现了问题，因此记下一笔。
常见的用户场景比如，用户在浏览器端填充完表单，然后提交，服务器端处理完，可以使用Forward的方式将用户转发到对应的页面，但Forward完成之前，用户有可能强制刷新页面，这样可能造成重复提交，因此可能会使用Redirect来响应用户：
这样的确可以减少服务端Redirect后的重复提交问题，但若在Redirect之前用户强制刷新，也会存在重复提交问题，其他防止重复提交的可以使用Token校验等方式，或者更好的方式是在浏览器端作一些前端优化，给予用户友好的等待提示。
Flash Attribute但使用Redirect后，相当于用户上一次Request的请求参数被丢失...阅读全文