法则及基本原则
这篇文章主要是记录一些生活或工作中基本原则,方便后续查看及思考。
在 Mysql 中,存储有三种日志,分别是 binlog log、undo log及 redo
log,其中 binlog 日志由 Mysql Server
生成,用来记录对数据库的更新操作,使用场景有主从同步及数据恢复;undo
log及 redo log由 Innodb
存储引擎生成,用于保障事务进行。undo日志用于事务的回滚及MVCC,实现事务的原子性,而
redo log基于 WAL( Write-Ahead Logging)
技术,存储事务过程中对数据表的修改,主要是数据页的修改,保证了事务的持久性。这三种日志在数据库表的更新操作(包括新增、修改及删除)中,相互配合,保障了事务的顺利执行,下图以一次数据更新操作演示了它们的工作机制。
在一致性算法中,Raft 及 Paxos 是强一致性的算法,属于 CP(一致性及分区容错性) 的使用场景,为了保证算法的准确性,必须保证大部分节点(服务器)是正常的(三个节点容忍一个节点失败)。但在 AP (可用性及分区容错性)场景中,即使只有少数机器的存在,仍然可以对外提供服务,这些场景包括:失败检测、路由同步、Pub/Sub 及动态负载均衡。而 Gossip 协议就是这样一种支持最终一致性算法的协议。
在分布式系统中,一个核心的问题就是解决数据一致性的问题,即共识问题(多副本共识问题):
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个类型:
这篇文章就四种类型的算法进行一个概要的分析,更多的是逻辑概念层面,不会对细节及实现过多讨论,那也超出本人的认知。
这篇文章主要讲述 select 和 epoll 的实现原理,包括底层的数据结构、与设备的回调处理机制及两种实现之间的差异。
这篇文章讲述网络报文从网卡 NIC (network interface controller)接收,再到操作系统网络协议栈处理,最后到用户程序接收报文处理报文的简化过程,希望能对TCP协议进行一个整体、概括性的总结。
几乎所有的现代编程语言都使用动态内存分配,即允许进程在运行时分配或释放无法在编译期确定大小的对象,这些对象的存活时间有可能超出创建者的生存周期。动态分配的对象存在于堆(heap)中而不是栈(stack)或者静态区(statically)中。在内存的管理方式上,有两种方式:1)显示内存释放,由开发人员显示的创建或释放对象;2)自动动态内存管理,由编程语言的运行时系统(虚拟机)负责内存的回收。自动动态内存管理可以显著地降低开发成本,提供程序的健壮性。我们这篇文章主要便是讲述内存管理中常用垃圾回收算法,并结合 java 来分析内部的实现。
垃圾回收的目的是回收程序不再使用的对象所占用的空间,任何具备自动内存管理系统的语言都要有三个功能:
内存分配与回收是相关性比较强的两个功能,内存管理系统都要具备这两个功能;在实现中,使用指针的可达性来近似对象的存活:只有当堆中存在一条从根出发的指针链能最终到达某个对象时,才能认定该对象存活,更进一步,如果不存在这一条指针链,则认为对象死亡,其空间可以得到回收。回收死亡对象包括两种方式:1)直接释放该对象,有可能会与前后的空闲对象进行合并;2)将存活对象进行移动或整理,减少内存碎片的问题。
之前给小孩和自己买保险走了一些弯路,特意研究了保险的品种及保障的作用,用思维导图做了一个总结,权当是笔记吧。