以太格

1. 概述

在分布式系统中，一个核心的问题就是解决数据一致性的问题，即共识问题（多副本共识问题）：

Consensus Problem : Requires agreement among a number of processes (or agents) for a single data value.

共识问题简单来说，就是多个进程（代理）就某个单值达成一致，主要的应用场景数据多副本的复制。而 Paxos 及 Raft 算法的提出便是为了解决共识问题，它们在工程实现上得到了广泛的应用，如 Goggle 的 Chubby、Apache 的 ZooKeeper 及 Raft算法实现 Etcd。这些算法都可以统称为一致性算法。

一致性算法大概可以分为4个类型：

1. Basic-Paxos : 提供就一个提案达成一致的算法，是最基本的算法，在工程实践中很少使用该算法；
2. Multi-Paxos : 在 Basic-Paxos 算法的基础上，提供了就一批提案达成一致的算法，在工程中有很多类似的实现；
3. Raft : 针对 Multi-Paxos 算法难于理解及实现复杂，提供了一种简化的实现；
4. Multi-Raft : 为了提供更大的并发请求量，可以将单个 Raft 集群进行分区，提供更大的集群规模。

这篇文章就四种类型的算法进行一个概要的分析，更多的是逻辑概念层面，不会对细节及实现过多讨论，那也超出本人的认知。

这篇文章主要讲述 select 和 epoll 的实现原理，包括底层的数据结构、与设备的回调处理机制及两种实现之间的差异。

这篇文章讲述网络报文从网卡 NIC （network interface controller）接收，再到操作系统网络协议栈处理，最后到用户程序接收报文处理报文的简化过程，希望能对TCP协议进行一个整体、概括性的总结。

在 垃圾回收之回收算法 这篇文章中预设了两个前提： 1. 根集合及对象中的指针集合已经得到； 2. 堆是可遍历的，即从一个对象可直接定位到下一个对象；

为了描述的方便，在上篇文章中直接得出了结论，而这篇文章的目的就是解释这两个问题。

这篇文章是对《高并发，你真的理解透彻了吗？》的记录及整理。

几乎所有的现代编程语言都使用动态内存分配，即允许进程在运行时分配或释放无法在编译期确定大小的对象，这些对象的存活时间有可能超出创建者的生存周期。动态分配的对象存在于堆（heap）中而不是栈（stack）或者静态区（statically）中。在内存的管理方式上，有两种方式：1）显示内存释放，由开发人员显示的创建或释放对象；2）自动动态内存管理，由编程语言的运行时系统（虚拟机）负责内存的回收。自动动态内存管理可以显著地降低开发成本，提供程序的健壮性。我们这篇文章主要便是讲述内存管理中常用垃圾回收算法，并结合 java 来分析内部的实现。

垃圾回收的目的是回收程序不再使用的对象所占用的空间，任何具备自动内存管理系统的语言都要有三个功能：

1. 为新对象分配空间；
2. 确定存活对象；
3. 回收死亡对象所占用的空间。

内存分配与回收是相关性比较强的两个功能，内存管理系统都要具备这两个功能；在实现中，使用指针的可达性来近似对象的存活：只有当堆中存在一条从根出发的指针链能最终到达某个对象时，才能认定该对象存活，更进一步，如果不存在这一条指针链，则认为对象死亡，其空间可以得到回收。回收死亡对象包括两种方式：1）直接释放该对象，有可能会与前后的空闲对象进行合并；2）将存活对象进行移动或整理，减少内存碎片的问题。

之前给小孩和自己买保险走了一些弯路，特意研究了保险的品种及保障的作用，用思维导图做了一个总结，权当是笔记吧。

1. 概述

处于优化的目的，在不同的编译器及不同体系架构的cpu 中，会将指令重排，即程序中排在后面的指令有可能比排在前面的指令先执行。同时由于cpu 中存在读写缓冲区，会将指令相关的运行时数据暂存在这些缓冲区中，也会导致指令重排的问题。目前的cpu 都是多核的体系架构，同一个语言编写的程序在不同硬件体系中，在多线程执行环境下，多次执行的结果可能不一致。在Java 中，怎么解决这个问题？为了屏蔽不同硬件架构的差异，给程序员提供一致的运行结果，Java 提出了 JMM(内存模型)的概念。

在数据库技术中，事务将应用程序的多个读、写操作捆绑在一起成为一个逻辑操作单元。即事务中的所有读写是一个执行的整体，整个事务要么成功（提交）、要么失败（中止或回滚）。如果失败，应用程序可以安全地重试。这样，由于不需要担心部分失败的情况（无论出于何种原因），应用层的错误处理就变得简单得多。

前段时间，需要对内存数据库ignite进行造型，将mysql与ignite进行了性能测试，这篇文章主要是讲在update操作上两者的差异。