qq_34673038的博客

Java垃圾回收机制 没有被任何对象引用就是垃圾 引用计数算法 每个对象有一个引用计数器 效率高 无法检测循环引用，内存泄漏 可达性分析算法 引用链可达来判断 可作为gc root对象 虚拟机栈中引用的对象 方法区域常量引用对象 方法区静态属性引用的对象 本地方法栈中JNI的引用对象 活跃线程引用状态 垃圾回收算法 标记清除法 标记 清除 缺点 碎片化 复制算法 分为对象面 和 空闲面 对象在对象面创建 存活对象被从对象面复制到空闲面 将对象所有对象内存清除 分代收集算法

进程和线程区别 进程独占内存空间，保存各自运行状态，相互不干扰，可以相互切换， 线程共享内存资源，相互切换更快，更加细粒度，进程内子任务可以并发进行 进程 资源分配最小单元 线程锁cpu调度最小单位 进程独立的，线程不是独立的 线程挂掉，整个进程都挂了 进程切换比线程切换开销大 java进程线程关系 进一步封装 进程和线程 运行一个程序会产生一个进程，进程包含一个线程 进程读应一个jvm实例，多个线程共享jvm主线程 主线程可以创建子线程，最后完成 Thread start run start 创建一个

java异常 what 什么被抛出 where 堆栈跟踪 why 为什么被抛出 String Buffer Error Exception区别 Error 程序无法处理的系统错误 编译器不做检查 Exception 程序可以处理的异常，捕获后可以恢复 总结 前者是程序无法处理，后者可以处理 RuntimeException 不可预知，程序应当自行避免 非RuntimeException 可以预知的，程序可以避免 编译器校验 Ioexp error jvm责任 runtimeexception 程序的

Spring IOC 控制反转 核心部分 依赖注入 DI 设计行李 轮子 依赖 地盘 依赖 箱子 依赖 行李箱 行李箱 注入 箱体 注入 地盘 注入 轮子 协同合作 共同开发 单元测试 更容易 DL依赖查找 侵入性 DI 依赖注入 方式 setter Interface Constructor Annotation 依赖倒置原则 高层不应该依赖低层 容器bean 避免new来创建类，统一维护 创建实例不想要了解细节 读取Bean配置信息 根据Bean注册实例化bean bean实例放到spri

Linux 体系结构 体系结构主要分为用户态 内核态 内核 本质是管理计算机硬件设备的程序 系统调用 内核访问接口， 共用函数库 系统调用的组合 shell 命令解释器 查找特定文件 find 制定目录查找文件 find ~ - name 检索文件内内容 grep 文件内热统计 awk 批量更改 sed ...

总结 缓存数据库 memcache redis 多路io复用 常用数据类型 分布式锁 异步队列、 海量数据固定前缀第key 持久化 aof rdb 混合 redis主从架构 加一个缓存层 在客户和存储 缓存穿透 和 熔断 memcache 代码层次类似hash 支持简单数据类型 不支持数据持久化 不支持分片 不支持主从 redis 数据类型丰富 数据持久化存储 主从 分片 10w qps 为什么这么快 基于内存 执行效率较高 数据结构简单 操作简单 kv 数据键值对 单线程 高并发 多核

如何设计一个关系型数据库 存储（文件系统） 程序实例 逻辑结构映射物理结构 存储管理 减少io次数 一次性读取多行 缓存机制 SQL解析 日志管理 权限划分 容灾机制 索引管理** 锁模块** 索引模块 为什么要索引 快速查询数据 什么信息成为索引 主键 唯一键 普通键 索引的数据结构 二叉查找树 平衡树 b+树 数可能偏移了——>平衡树 B-Tree 最多n个孩子 根节点至少2孩子 每个节点最多m个孩子 除了根节点和叶节点，每个节点至少m/2 孩子 所有叶子节点都在一层 每个

OSI 开放互联参考模型 七层协议 物理层 bit 网线类型 传输介质 10二进制数据转电流 数模转换 网卡工作 数据链路层 格式化数据进行传输 错误检测 纠正 帧 交换机 网络层 路由器 分组传输 ip协议 包 传输层 segment 传输质量 tcp udp 协议 分片 序列号 会话层 建立管理应用程序 表示层 不同通信系统能理解的解析 应用层 http协议 TCP/IP 应用层 传输层 网络层 链路层 TCP 三次握手 tcp 传输控制协议 面向连接，可靠，基于字节流的传输层控制协议 应用层

6.824 讲座14：参数服务器案例研究 使用参数服务器扩展分布式机器学习 Li，Andersen，Park，Smola，Ahmed，Josifovski，Long，Shekita，Su OSDI 2014 如今：分布式机器学习 案例研究：参数服务器 我们为什么要阅读这篇论文？ 有影响力的设计 宽松的一致性 不同类型的计算 机器学习入门 模型是函数逼近器 真正的函数是未知的，所以我们从数据中学到一个近似值 例如：-f（用户个人资料）->广告点击的可能性 -f（图片）->图片可能包含一只猫 -f（

6.824 讲座13：Naiad案例研究 Naiad：及时的数据流系统 默里，麦克谢里，以撒，艾萨德，巴勒姆，阿巴迪 SOSP 2013 如今：流和增量计算 案例研究：Naiad 我们为什么要读《 Naiad》？ 优雅的设计 令人印象深刻的表现 开源且仍在开发中 总结：Spark提高了迭代计算的性能 即，一次又一次使用相同数据的数据 但是如果输入数据发生变化怎么办？ 可能会发生，例如因为搜寻器更新页面（新链接） 或因为应用程序将新记录追加到日志文件 实际上，Spark（如上一课的论文一样）必须重新开始！ 即

6.824 讲座12：Spark案例研究 弹性分布式数据集：内存群集计算的容错抽象 Zaharia，Chowdhury，Das，Dave，Ma，McCauley，Franklin，Shenker，Stoica NSDI 2012 如今：更多分布式计算 案例研究：Spark 我们为什么要阅读Spark？ 广泛用于数据中心计算 受欢迎的开源项目，热启动（Databricks） 比MapReduce更好地支持迭代应用程序 有趣的容错故事 ACM博士论文奖 MapReduce使程序员的生活变得轻松 它处理： 节点之

6.824 讲座10：FaRM 我们为什么要阅读这篇论文？ 很多人想要分布式交易 但他们被认为是缓慢的 本文提出的建议不一定非要如此-非常令人惊讶的表现！ 大业绩图 每秒9000万个复制 持久 事务（图7） 每台机器每秒100万笔交易 每个都有一些消息，用于复制和提交 非常令人印象深刻 其他一些系统则每台机器每秒获得100万次操作，例如memcached 但不是事务+复制+持久性（通常这些都不是！） 9000万的观点： 每秒10,000条推文 每秒2,000,000封电子邮件 他们如何获得高性能？ 数据必须

6.824 讲座10：分布式事物 主题： 分布式事务=并发控制+原子提交 有什么问题？ 很多数据记录，分片在多个服务器上，很多客户端 [图：客户端，服务器，按密钥分片的数据] 客户端应用程序操作通常涉及多次读取和写入 银行转帐：借方和贷方 对文章进行投票：检查是否已投票，记录投票，增加计数 在社交图中安装双向链接 我们想向应用程序编写者隐藏交错和失败 这是传统的数据库问题 当今的资料源自[分布式]数据库 但是这些想法被用于许多分布式系统 示例情况 x和y是银行结余-数据库表中的记录 x和y在不同的服务器上（

6.824 讲座8：Zookeeper案例研究 阅读：“ ZooKeeper：互联网级系统的无等待协调”，Patrick 亨特，马哈德夫·科纳尔，弗拉维奥·P·琼奎拉，本杰明·里德。2010年会议论文集 USENIX年度技术会议。 我们为什么要阅读这篇论文？ 广泛使用的复制状态机服务 受Chubby（Google的全局锁定服务）启发 最初在Yahoo !，现在也在外部（Mesos，HBase等） 开源的 作为Apache项目（http://zookeeper.apache.org/） 给Paxos / ZA

lecture 7：木筏（3）-快照，线性化，重复检测 本讲座： 木筏快照 线性度 重复的RPC 更快得到 ***筏日志压缩和快照（实验3B） 问题： 日志将变得巨大-比状态机状态大得多！ 重新启动或发送到新服务器将花费很长时间 幸运的是： 服务器不需要既完整的日志又服务状态 在状态中捕获日志的执行部分 客户只看到状态，而不是日志 服务状态通常要小得多，所以让我们保持 服务器不能丢弃哪些条目？ 未执行的条目-尚未反映在状态中 未提交的条目-可能是领导者多数的一部分 解决方案：服务定期创建持久的“快照” [图

6.824 讲座6：raft（2） 回顾： 键/值服务为例，如实验3所示 目标：多机看起来和单机一样 目标：尽管有少量故障/断开服务器，但仍可用 高可用 提防网络分裂和裂脑！ [图：客户，k / v层，k / v表，筏层，筏日志] [客户端RPC-> Start（）->多数提交协议-> applyCh] “状态机”，应用程序，服务 一些提醒： 领导者在多数回复AppendEntries之后提交/执行 领导者告诉对执行者的提交，执行（==在applyCh上发送） 为什么只等待大多数？为什么不

6.824 2017讲座5：筏（1） 我们为什么要阅读这篇论文？ 分布式共识是人们数十年来一直努力解决的难题 实验2和3基于Raft 这个讲座 今天：筏选和日志处理（实验2A，2B） 下一页：筏持久性，客户端行为，快照（实验2C，实验3） 总体主题：使用复制状态机（RSM）的容错服务 [客户端，副本服务器] 示例：配置服务器，例如MapReduce或GFS主服务器 示例：键/值存储服务器，put（）/ get（）（lab3） 目标：对于用户来说看起来和单机一样 但尽管有一些故障服务器也可用（高可用） 战略：

主备复制 主题 容错的主从复制 VMware FT的案例研究 这个主意的实现版本 容错 我们想要一个一个服务出现错误也能继续运行 一些理想的模型 高可用：尽管一些错误，但是仍然能用 强一致性：看起来就像单机服务 client透明 server 软件透明 有效率 我们需要处理哪些错误？ 崩溃 独立的失败 网络丢包 网络分区 但不包括 执行不正确 不相关的错误 配置错误 恶意代码 行为 可用 (如服务器崩溃) 等待(网络错误) 永远停止(多个服务器崩溃) 故障(软硬件错误，软件故障)

GFS The Google File System 为什么读这个paper 文件系统使用mr 6.824的主题在论文中体现 简单且表现良好的交易一致性 为之后的设计提供了思路 优秀的系统论文-app的细节，包或网络性能，错误容忍，一致性 影响 很多文件系统使用GFS () GFS (e.g., Bigtable, Spanner @ Google) HDFS (Hadoop Distributed File System) based on GFS 什么是一致

基础架构：RPC和线程 最常见的问题：为啥用Go? 6.824使用c++很多年 c++工作良好 但是学生花费很多时间追踪指针和alloc/free错误，而且缺乏满意的c++rpc包 go对我们来说更好 并行更好的支持 rpc更好的支持 gc垃圾收集 类型安全 线程安全的gc是很有吸引力的 go编程是愉快的 相对简单且传统 Threads 线程是有用的架构工具 Go叫他们协程，其他编程语言叫他们线程 非常tricky 为啥要threads? 我们需要并行，这在分布式系统很常见，io并行