计算机系统
未读Replicated State Machines备份状态机，每个机器单独为一个状态机，他们具有相同的初始状态，转换规则，以及输入的顺序也是一致的，对于特定的输入的转换也是确定而非模糊的（Determined State Machine）；问题在于，如果请求是分别由客户端发往不同的备份机器上的，那么顺序根本无法保证primary-backup model 首先使用primary机器来为每个输入确定好排序后发给每个备份机器，而primary本身也需要一个备份机器来进行备份自身排好的输入顺序，这样在主机器挂了之后还有个backup顶住
这里其实关键的问题就是，如何控制每个机器接收到的请求的顺序是完全一模一样的，此处使用了primary-backup的机制，也就是每个记录数据的节点还需要一些备份节点同步更改在一个分布式体系中，有不止一个coordinator，一个coordinator负责不同的客户们的请求，而且还决定了体系中哪一个数据节点是priamry；请求会被coordinator转发到primary node中，而backup node则负责接收primary的指令并且返回ACK；但 ...
计算机系统
未读Consistency under single-node faults这里举了一个例子其实就是讲事务，如何保证一串操作的原子性，由银行转账问题来引出原子性问题，因为这对于单机来说已经不是通过设计一致性策略能够修复的了，需要针对单机来进行事务处理策略的设计
shadow copy：将需要写的文件拷贝一份，写的时候写在临时拷贝文件中，最后将文件改名（指针指向修改完的文件）；如果在fcopy fsync处出问题不会影响原子性，如果在rename处出问题则可以先将rename需要做得持久化操作先保存到磁盘上（称为journal），随后假设record未执行完全则可以通过journal来恢复，而本身如果在磁盘执行的时候断电，则可以给磁盘添加一些电子元件，让其能够在一定时间内保持继续写入数据的电力shadow copy对付大型文件的性能不太行，比较适合修改元数据；而且对于多线程请求，shadow copy首先不能针对两个同时写同一个文件的请求去各自copy一份，因为这样显然会造成复写，但是有可能一个线程写完了之后他直接rename了，那么其他线程可能还没更新完毕，假设其他线程在重新更新的之前宕 ...
计算机系统
未读LSM Tree
对文件的增删改查通过append进行，因为文件顺序读取远快于随机读取（点查询）
在内存中需要有一个index用来存储byte offset，来标记key对应的位置，这本质上也是一个内存的KV；可以通过布谷鸟哈希来实现：优点，GET很快；缺点：INSERT可能会不成功，以及假设有大量的数据（导致触发了多次死循环等），需要扩容，扩容不仅要重新分配内存，还要重新设置哈希函数，重新将数据塞进去
append操作会导致文件无限扩充，对于冗余数据（比如键值存储中已经过时的键值对），需要进行淘汰旧值的compaction，类似于LSM的操作
垃圾回收：将空值（表示被删除）在重新进入内存的时候进行垃圾回收
B+Tree不适合insertion-intensive类型的存储情景
分层存储SSTable：除了L0层以外其余层都根据键值对的顺序和时间戳进行了排序（优先以时间戳），这样是方便于对于一个key的查找，在假设时间戳一致的情况下，对于同一层的SSTable，只需要查找一个，其余的不需要查找（因为范围已经对不上了）
崩溃恢复：redo log，没有持久化之前先把自己写在内 ...
计算机系统
未读分布式文件系统用处广泛，比如网盘等常用应用就使用了这个系统
NFS with RPCNetwork File System希望提供一个服务端无状态、客户端无磁盘的服务；它为客户端提供了一些fs api接口，客户端向服务端发送file handler(not fd!)
客户端将fd和fh关联，在服务端不需要维护fd状态
服务端若维护状态，维护的数量和与之连接的客户端数量成正比，内存负担较大
服务端若断电，客户端无感知，但是客户端已经无法通过本地维护的fd访问服务端的文件
无服务处理写操作有一定问题：因为可能会有retry请求的发生，这对于请求的幂等性需要做一定的规定，否则会导致一些奇怪的现象发生（比如at-most-once）
什么是file handler？客户端维护的访问远端文件系统的信息，但是又不仅仅使用/path/to/remote/file或者inode来标识
仅使用文件名会导致在客户端1访问文件两次的间隙，文件被改名并且别的文件顶替了该文件名，导致两次访问的文件不同
仅使用inode会导致在客户端1…，远端文件被删除，又被新建一个文件，那么这个inode肯定不是指向原来 ...
计算机系统
未读RPC是使得本地程序可以远程调用远程的函数的一种技术，从实现层面看可以用TCP/UDP方式进行传输，有gRPC等框架来实现，在具体细节上和HTTP有许多不一样的地方，因为他是直接请求调用远程的某个函数并获取返回值
C/S客户端视角的RPC接口：主要封装需要调用的远程函数的标识、参数、主机，并等待返回值；需要封装：Xid（事务id）、program（程序号）、procedure（函数号，表示第几个程序的第几个函数）服务端视角的RPC接口：主要封装等待请求和响应请求的过程，而调用函数由rpc请求内容决定；返回包括Xid、是否接受、是否处理成功、结果可以通过program number找到可执行文件，或者通过端口来找到正在执行的程序并请求他调用
请求细节客户端传送给服务端的数据应该是拷贝而不是指针，因为传指针一个是远程服务器不好读取该虚拟地址内容，第二个是可能会被修改
数据兼容性：例如大小端法、浮点数、对齐方式等
版本兼容性：rpc版本是否兼容
数据编码方式：
JSON：易读，方便debug；数据量大、不好处理二进制数据（Base64）、一些数据类型在不同机器上存储方式 ...
计算机系统
未读lec03 inode fs
文件事实上是binary array(durable and has a name)
block用来存储多个sector，一个sector是disk driver接口读取和写入的最基本单元，为了保证index存储的大小不会太大（sector比较小，意味着index比较多，意味着需要用比较多的byte去表示），加一层block用来减少index的位数
一般一个block只被一个file占用，即使空间被浪费
元数据的存储：
superblock存储block size等较为通用的元数据
inode bitmap存储空inode的index
block bitmap存储空block的index，$(0|1)^+$
使用inode来存储单个file，inode结构为：由直接指向Data Block和指向Indirect Block的指针构成，最后汇集成一个file
使用一个叫做inode table的mapping表来存储每个inode file的block位置，并标记是否为空闲等
将文件名和inode的映射关系存放在称为directory的地方，dire ...
本博客采用Hexo框架搭建，通过github.io挂载，并且使用安知鱼主题进行美化。初次尝试仍有考虑不周致使博客观看效果体验不佳等问题，后续会持续考虑利用框架中的优秀feature美化个人博客。
快速入门指北Hexo使用我刚开始对于Hexo一无所知，所幸该框架十分易学，参考B站视频快速入门；不过在npx hexo d的时候出现了问题，主要原因是没有安装hexo-deployer-git插件
1$ npm install hexo-deployer-git --save
然后都算顺利，注意需要记住自己的ssh的passphrase，或者干脆不设置（我记得好像当时因为在服务器开发为了防风险之类的设置的emmm），不然就像笔者一样搞不清楚情况，试了好多次
安知鱼框架感谢大佬开源，框架入口，总体比较好入门，主要修改hexo根目录下的_config.anzhiyu.yml，根据文档修改即可。
博客的各种主题的配置主要还是从_config.anzhiyu.yml以及_config.yml进行修改，人为改.css通常不会奏效，因为我现在发现npx hexo cl会清除所有前端相关文件，在npx h ...
