仅记录简单的命令，详细请自行搜索

扫描指定网段下的所有IP

• nmap: 网络探测和安全审核工具，它的设计目标是快速地扫描大型网络

$ nmap -nsP 10.1.xx.xxx/27

Starting Nmap 6.40 ( http://nmap.org ) at 2020-09-25 20:02 PDT
Nmap scan report for 10.1.xx.xxx
Host is up (0.0022s latency).
Nmap scan report for 10.1.xx.xxx
Host is up (0.0025s latency).
Nmap scan report for 10.1.xx.xxx

查看开放的端口

• netstat: 显示服务器的网络状态

# 显示打开的 TCP 端口
$ netstat -ntpl

记录自己在系统设计与开发中那些踩过的坑或者觉得重要的条目

1. 统一语言：一个团队，一种语言
2. 核心模型：精炼系统中最有价值的部分
3. 边界与划分：服务的边界以及横向划分与纵向划分
4. 结构与层次：保证清晰的、有序的结构与层次关系
5. 转换层：正确处理与外部系统的关系
6. 弹性：容错与自动修复能力
7. 保持简单：让开发更简单、让运维更简单、让使用更简单
8. 产品思维：避免因为程序员思维让用户感到困扰

定义

TCP 是一个面向有连接的、可靠的通信服务协议

连接

• 为什么需要三次握手：
  1. 为了实现可靠的数据传输，TCP 协议的通信双方都必须维护一个序列号（Sequence number），以标识已经发送出去的数据包中，哪些是已经被对方收到的。所以三次握手的过程是通信双方相互告知与确认序列号起始值的必经步骤。如果只是两次握手，则至多只有连接发起方的其实序列号能够被确认；
  2. 为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误；
     
• 为什么序列号不从 0 开始：
  1. 预防 TCP 序列预测攻击，参考：https://en.wikipedia.org/wiki/TCP_sequence_prediction_attack；
  2. 尽可能的避免数据混淆（2msl可以解决）；
• 为什么需要四次挥手：TCP 是全双工通讯协议，关闭连接时，服务器端收到对方的 FIN 报文，仅代表对方不在发送数据了，但是还是能够接受数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

数据的发送

• 保证可靠性传输的机制：通过校验和（Checksum）、序列号（Seq）、确认应答（Ack）、重发控制、连接管理、窗口控制等机制实现可靠性传输；
• 单位：TCP 以段为单位发送数据，每段消息的最大长度被称为 MSS（Maximum Segment Size）,MSS 是在三次握手通过双方协商而成（选择两者中相对更小的值）；
• 可靠性：数据的发送通过序列号与确认应答来提高其可靠性：如果发送端在一定的时间内没有等到确认应答，那么发送端会认为数据已经丢失，并进行重发。由此可以保证，即使产生了丢包，仍然能够将数据发送出去；
• 重发超时如何确定：每次发包时都会计算往返时间及其偏差，将这个往返时间和偏差相加，重发超时时间就是比这个总和要稍微大一点的值；
• 滑动窗口控制：通过窗口提高发送速，其类似于阻塞队列似的缓冲区，以使得发送数据时不必每次发送完消息都必须等待应答后才能继续发送下一次的消息。同时确认应答也不再是以每个分段，而是以更大的单位进行确认时，转发时间将会被大幅度的缩短。窗口的滑动是在收到确认应答后，将窗口滑动到确认应答中的序列号的位置。
• 窗口控制与重发控制：发送端仅需要通过最后一次确认序列号来确定哪些消息发送成功了，而不必对所有没有收到确认应答的数据都进行重；
• 流控制：
  1. 动态调整窗口大小：接收端可以根据自己的实际接受能力动态的来向发送端告知自己可以接受数据的大小，发送端收到后，发送的数据不会超过这个大小；
  2. 窗口探测：为了避免缓冲区满了之后，无法继续发送数据的同时更新窗口大小的通知被丢失，此时发送端会时不时的发送一个叫做窗口探测的数据段，此数据仅包含一个字节以获取最新的窗口大小信息。
• 拥塞控制：
  1. 慢启动：即初始窗口（拥塞窗口）大小为1MSS，然后的大小每收到一次确认应答就增加1，最终发送端能够发送的数据是接收端通知的窗口大小与拥塞窗口的大小中较小值还要小的值；
  2. 慢启动阈值：如果拥塞窗口的值超出这个阈值，在每收到一次确认应答时，只允许以下面这种比例方法拥塞窗口：1个数据段的字节数 / 拥塞窗口（字节） * 1个数据段字节数
• 提高网络利用率的一些规范：
  1. Nagle 算法：如果发送端还有应该发送的数据，但是这部分数据很少的话，则进行延迟发送的一种处理机制；
  2. 延迟确认应答：接收端收到数据以后，并不立即返回确认应答，而是延迟一段时间，从而减少应答数量；
  3. 捎带应答：确认应答和回执数据通过一个包发送的方式，即回执数据时捎带了一个应答。这样可以减少包的发送次数；

附录1：TCP 状态变更图

CAS

源码

Unsafe.class 中声明 compareAndSwap 的 native 方法：

public final native boolean compareAndSwapObject(Object var1, long var2, Object var4, Object var5);

public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);

compareAndSwap native 方法的实现： unsafe.cpp L1607 & unsafe.cpp L1185

static JNINativeMethod methods_18[] = {
    {CC"compareAndSwapObject", CC"("OBJ"J"OBJ""OBJ")Z",  FN_PTR(Unsafe_CompareAndSwapObject)},
    {CC"compareAndSwapInt",  CC"("OBJ"J""I""I"")Z",      FN_PTR(Unsafe_CompareAndSwapInt)},
    {CC"compareAndSwapLong", CC"("OBJ"J""J""J"")Z",      FN_PTR(Unsafe_CompareAndSwapLong)},
}

UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x))
  UnsafeWrapper("Unsafe_CompareAndSwapInt");
  oop p = JNIHandles::resolve(obj);
  jint* addr = (jint *) index_oop_from_field_offset_long(p, offset);
  return (jint)(Atomic::cmpxchg(x, addr, e)) == e;
UNSAFE_END

最终调用了 Atomic::cmpxchg(x, addr, e) 方法

linux_x86 的实现： atomic_linux_x86.inline.hpp L93

inline jint     Atomic::cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value) {
  int mp = os::is_MP();
  __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
                    : "=a" (exchange_value)
                    : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
                    : "cc", "memory");
  return exchange_value;
}

说明：

• os::is_MP()用于判断计算机系统是否为多核系统；
• __asm__表示接下来是内联的汇编代码；
• volatile表示禁止编译器优化；
• LOCK_IF_MP是一个内联函数，用于在多核处理器上的指令中添加 lock 前缀，源码：atomic_linux_x86.inline.hpp L147

  // Adding a lock prefix to an instruction on MP machine
  #define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: "

• 最终会调用 cmpxchgl 指令；

总结：

• CAS 最终使用 lock cmpxchg 指令实现，如果是单核处理器则没有 lock 前缀；
• 对于使用 Java 语言而言，CAS 是无锁的；但是对于 CPU 的实现而言，它是可能存在锁的；

raft 分布式共识

节点的状态

• Follower：追随者
• Candidate：候选人
• Leader：领导人

Log Replication：日志复制

• 系统的所有更改都只能通过 leader 进行；
• 更改条目时，首先追加到 leader 日志中，但是处于未提交的状态；
• 然后 leader 将请求复制到所有的 follower 节点，并等待，直到大多数节点都写入了该条目；
• leader 确认大多数节点写入成功后，会提交该条目，并随后通知各个 follower 提交该条目；
• follower 更新完成后，系统便已达成共识；

Leader Election：领导者选举

• 概念：
  • 选举超时（election timeout）：追随者成为领导者之前所等待的时间，此值被随机分配在 150ms - 300ms 之间；
• 选举过程：
  • 选举超时后，追随者将成候选人，并开始一个新的选举任期（election term）；
  • 候选人会为自己投票，并将请求发送至其它节点以争取选票；
  • 如果其它节点在此选举任期内还没有投票，那么它将把票出给候选人，然后将重置选举超时；
  • 一旦候选人获得多数选票，那么它将成为领导者；
• 心跳：
  • 领导者开始向追随者发送“添加条目（Append Entries）”的消息，这些消息的间隔时间为心跳超时（heartbeat timeout）的时间，然后追随者将响这些“添加条目”的消息；
  • 此选举任期将持续到追随者停止接收心跳，并成为候选人为止（比如领导者死亡，然后无法发送消息）；

如何解决网络分区的问题

1. 网络分区后，节点数量较少的那部分分区无法完成新任期的 Leader 选举，并且无法提交条目；
2. 网络分区后，节点数量较多的那部分分区可正常的选举、提交条目；
3. 网络正常后，较少节点的那部分节点因为没有新的数据写入，所以只需要回滚之前未提交的数据，并同步数量较多的那部分节点中的数据即可；

Consumer poll and rebalance

通过 Wireshark 抓包以及 Debug 源码，对 Consumer poll 及 rebalance 相关操作得出以下结论：

1. new KafkaConsumer() 以及调用 consumer.subscribe() 方法时不会产生实际的 TCP 连接；
2. 只有在需要从服务器获取信息时，才会通过一个叫 Fetcher 的代理类去连接服务器，并执行所需的操作；
3. 只有调用 consumer.poll(...) 方法后，才会启动心跳线程。同时将 consumer 加入到 group 中，也即是此时才会进行 rebalance 操作；
4. 调用 consumer.poll(...) 操作时，实际执行了如下操作：
   • 1) 确保 coordinator 准备就绪；
   • 2) 确保该 group 处于活动状态；
     • 2.1) 确保 coordinator 准备就绪；
     • 2.2) 启动心跳线程（如果有必要）；
     • 2.3) 加入 Group（如果需要，此时应该就是由服务器进行 rebalance 操作了）；
   • 3) 检查心跳的状态，并指示客户端的活动状态（并未真正提交心跳，只是更改了心跳类中的一些指标数据。心跳由心跳线程轮询提交）；
   • 4) 自动提交 offset（如果有必要则进行异步提交）；
   • 5) 拉取并返回数据；

RIT

• Spring 的作用
• 为什么系统设计中边界很重要
• 编程是一项结构性的社会创造
• 系统复杂性
• 反分工
• 领域模型

数据类型映射关系

目录

• 业务分析
• 应用设计
• 技术设计
• 数据设计
• 非功能性设计