从Go 1.7 runtime包理解Golang GC Go也是垃圾回收的，实现方式和别的语言不太一样。 先从Go的标准库的runtime包说起，这个包有很多运行时相关的类型和函数。 调用runtimea.GC()可以触发GC，但我们一般不会这么做，先读一下这个函数的注释说明。 GC runs a garbage collection and blocks the caller until the garbage collection is complete. It may also block the entire program 大概的意思是，Go的GC触发时会阻塞整个程序的运行。这个在垃圾回收里面有一个比较有名的名词叫STW，Stop the World。就是说程序在GC时“整个世界会停止下来”。 Go垃圾回收的STW一直是Go语言被指责和诟病最多的地方，也是Go的每个版本都努力改进的地方。
MySQL日志类型 错误日志(Error log): mysqld启动，运行，停止相关的警告或错误信息 普通查询日志(General query log): 记录从连接客户端发出的SQL语句和MySQL命令 二进制日志(Binary log): 对数据库执行更新的语句，二进制日志也被用来在主从复制时使用 中继日志(Relay log): 主库推送的主库二进制日志中的事件到从库的中继日志，从库根据中继日志重做数据变更操作 慢查询日志(Slow query log): 执行时间超过long_query_time设定值的SQL语句，也可包含没有使用索引的SQL语句 DDL log (metadata log): Metadata operations performed by DDL statements 错误日志 MySQL的错误日志是默认开启，且必须开启。查看错误日志的位置：
关于leader的选举，Zookeeper提供了三种方式：LeaderElection, AuthFastLeaderElection, FastLeaderElection。 其中FastLeaderElection是Zookeeper默认使用的。 当ZK服务启动的时候首先要做的事情就是Leader的选举。在选举过程中，每个zk server会有以下四种选举状态：
map的内部结构 Go中的map使用哈希表实现的，在源码go runtime/hashmap.go中可以看到对应实现。 // A header for a Go map. type hmap struct { // Note: the format of the Hmap is encoded in ../../cmd/internal/gc/reflect.go and // ../reflect/type.go. Don't change this structure without also changing that code! count int // # live cells == size of map. Must be first (used by len() builtin) flags uint8 B uint8 // log_2 of # of buckets (can hold up to loadFactor * 2^B items) noverflow uint16 // approximate number of overflow buckets; see incrnoverflow for details hash0 uint32 // hash seed buckets unsafe.Pointer // array of 2^B Buckets. may be nil if count==0. oldbuckets unsafe.Pointer // previous bucket array of half the size, non-nil only when growing nevacuate uintptr // progress counter for evacuation (buckets less than this have been evacuated) // If both key and value do not contain pointers and are inline, then we mark bucket // type as containing no pointers. This avoids scanning such maps. // However, bmap.overflow is a pointer. In order to keep overflow buckets // alive, we store pointers to all overflow buckets in hmap.overflow. // Overflow is used only if key and value do not contain pointers. // overflow[0] contains overflow buckets for hmap.buckets. // overflow[1] contains overflow buckets for hmap.oldbuckets. // The first indirection allows us to reduce static size of hmap. // The second indirection allows to store a pointer to the slice in hiter. overflow *[2]*[]*bmap } // A bucket for a Go map. type bmap struct { // tophash generally contains the top byte of the hash value // for each key in this bucket. If tophash[0] < minTopHash, // tophash[0] is a bucket evacuation state instead. tophash [bucketCnt]uint8 // Followed by bucketCnt keys and then bucketCnt values. // NOTE: packing all the keys together and then all the values together makes the // code a bit more complicated than alternating key/value/key/value/... but it allows // us to eliminate padding which would be needed for, e.g., map[int64]int8. // Followed by an overflow pointer. } 先删掉代码原有注释，以便于查看：
slice的内部结构 一个slice本质上是一个数组的某个部分的引用。在go runtime/slice.go源码中定义了slice的结构： type slice struct { array unsafe.Pointer len int cap int } 可以看到在Go的内部，slice是一个包含3个字段的结构体：
iptables是带有状态机制的防火墙，可以跟踪连接状态，我们可以根据状态编写更细致的规则。 iptables可以跟踪一下四种状态： NEW 客户端向服务端主机发出一个连接请求，该数据包的状态就是NEW ESTABLISHED 连接建立后，使用该连接通信的数据包的状态就是ESTABLISHED RELATED： 该数据包正在启动新的连接，它还和某个已经处于ESTABLISHED状态的连接有关系 INVALID 表示该数据包与任何已知的连接都不关联，数据包可能包含错误的头和数据，即无效的数据包，通常这种状态的数据包会被丢弃 例如：
iptables是Linux中基于内核的防火墙，功能十分强大。 iptables工作在网络层，不需要把数据发送到用户空间，在系统内核空间中进行数据过滤可以保证数据处理效率。 当数据包到达iptables之后，如果MAC地址相符，就会由内核中的相应驱动程序接收，通过一系列操作决定将数据包发送给本地程序或转发到其他主机，或进行其他操作。 iptables由一系列表(table)组成，表再由一系列链(chain)组成，当数据包到达iptables之后，就会基于规则按一定顺序穿越不同的表和链。
理解Swap Space 对服务器进行性能监控，除了CPU, 内存, 磁盘IO,网络外，Swap Space也是值得关注的关键项。 用户进程在内存空间中数据有以下形式： 程序代码和共享库 文件内容的缓存数据 程序使用的堆栈空间 其中前两项都是从文件系统中读取进来的。 Linux本身是一个分页请求系统，用户进程使用的内存需要映射到物理内存。为了更好的使用内存，Linux会对物理内存中的页面进行回收：
MySQL的多源复制(multi-source replication)允许将一个MySQL从库连接到多个主库，并从每个主库获取和复制数据更改。这种复制拓扑结构可以实现在多个数据库服务器之间进行数据同步和复制。 传统的MySQL复制是单源复制，其中一个主库（也称为主服务器或主节点）将其数据更新记录在二进制日志中，并将这些日志传播给一个或多个从库（也称为从服务器或从节点）。每个从库通过读取主库的二进制日志并应用这些更新来保持与主库的数据同步。
MySQL常见复制模式 MySQL的常见复制模式(假设有DB1,DB2,DB3三个MySQL实例): 主从复制 DB1 -> DB2 主主复制 DB1 <- -> DB2 链式复制 DB1 -> DB2 -> DB3 环形复制 DB1 -> DB2 -> DB3 -> DB1 生产环境常见主从复制，这是最稳健的一种方式；为了切换方便也可选择主主模式，但要注意主主复制必须确保在任何时刻只有一个数据库是master写入状态，否则可能导致数据异常。 链式和环形复制在生产环境很少使用，主要的缺点是随着节点的增加整个复制系统的稳健性会下降。