本科毕业设计: 由于本人的表述和组织的水平较差,有很多写得不好的地方,这些能力以后加强锻炼。最后的一段实现也很懈怠,只想着早一些完成。 因为我想写的是总的架构设计,但由于篇幅的原因,所以很多算法,设计理念都没有写清楚。还有一些是自己的见解,因为老师不是研究这个方向的,所以没有提一些意见,不保证正确性。如果说的有哪些不正确的地方敬请指正。
go 实现设计模式
参考文章: [理解 Go interface 的 5 个关键点](http://sanyuesha.com/2017/07/22/how-to-understand-go-interface/)其中描述有一些错误,但是讲了大部分的知识点了。 [Java开发中的23种设计模式详解(转)](http://www.cnblogs.com/maowang1991/archive/2013/04/15/3023236.html)
软技能-代码之外的生存指南
原书购买链接:[软技能-代码之外的生存指南](https://www.amazon.cn/dp/B01IB086H4) John Z. Sonmez 著 王小刚 译
发现我现在有很多观点和作者有些相似了,在学习方法上和锻炼上也有很多和作者相近。只是我现在已经22岁了,才即将开启自己的人生,都在尝试阶段。作者以一个过来人总结了大量的经验,看完这本书之后将自己的一些总结放在这里,以惊醒自己和给读者一些参考。
招聘的 home exercise
招聘的第一个home exercise。
raft 寻找一种易于理解的一致性算法
翻译参考: https://github.com/maemual/raft-zh_cn/blob/master/raft-zh_cn.md 英文原文: [In Search of an Understandable Consensus Algorithm](https://raft.github.io/raft.pdf)
根据Raft的满足特性,将raft分解成领导选举,日志复制,安全性。分别阐述每个部分的内容。同时讲解成员变更,日志压缩和客户端与Leader的交互的过程。
分布式事务之两阶段提交
文章主要引用自 http://duanple.blog.163.com/blog/static/70971767201311810939564/ 他的博客给我提供了很多帮助。感谢!
在看这篇文章之前我一直有一个疑惑,2pc和raft有什么局别(2pc也可以实现一致性,副本的一致性为什么不用2pc)? 现在大约有一个答案了:2pc更加注重的是当前的一个事件(不用事务的原因是不一定只能用于事务)在系统中都达到一致之后才认为这个事件是完成了的。而raft等只要大多数达到一致就可以了,其他不一致的节点可以后面慢慢追上。这使得2pc和raft有了不同的分工
下面2pc没有解决协调者挂掉时,而所有参与者都处于不确定区间时的情况,所有参与者都在等待协调者的恢复,因为参与者不能确定事务的状态。 我的想法是在客户端中维持一个与协调者的心跳如果协调者故障,则重新安排协调者,并且重新发送vote-req信息,这些2pc,不过相应的参与者中的代码机制就要改一下了,在超时执行termination protocol之前看看没有有vote-req消息。
percolator:在线增量处理系统 中文翻译
原文:[Large-scale Incremental Processing Using Distributed Transactions and Notifications](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Peng.pdf) 使用轻量级通知+轻量级事务解决大规模增量系统问题。
翻译和阅读这篇论文的时候对麻烦的是对Google索引的增量处理做了哪些事不是很清楚。造成论文理解不深,以后再读。
关系型数据库之范式
关系数据库设计的目标是生成一组关系模式 使我们存储信息时避免不必要的冗余,并且让我们可以方便地获取信息。 这是通过设计满足适当范式(normal form)的模式来实现的。
hexo基于NexT主题订制自己的主题
前言
写了几天的博客之后发现,连我自己都没有兴趣查看自己的博客。
觉得只给予自己那浅薄的markdown语法,和NexT官方的默认配置。继续写作是不行了。
而自己没有一点前端的知识背景,最近时间也比较紧能解决目前的需求就行了,没有深究进去。
下面的一些配置和文章中的写法主要参照:打造个性超赞博客Hexo+NexT+GithubPages的超深度优化
上面一篇的配置及其详细,阅读起来时间成本比较高。下面总结出一些我认为我自己写博客的一些刚需,并给出相应的解决方案。
部署与使用见上一篇:hexo部署与使用入门
NexT 主题订制
默认的主题,存在下面一下我不喜欢的配置,
- 我使用Mist主题,其中首页中前十个网页是全量显示的其实我只想要显示简介就行了。
- 网页之间没有之前没有明显的边界线,区分度不大。
- 链接采用暗黑的风格,不明显。
- 首页只能按照date排序,我想要自定义一些排序。
- hexo new 产生自己需要的默认配置
- markdown在网页中子标题和文本的区别度不大。
解决方案:
问题2,3,6在 themes/next/source/css/_custom/custom.styl
中添加自己的配置。
配置如下:我自己的配置
问题1:
1 | # Automatically Excerpt. Not recommend. |
问题4:
1 | # 卸载默认按照的插件,安装新的插件。 |
要排序文章只要在Front-matter
中 添加 top: num。
之后就可以按照num排序了。
问题5:
更改scaffolds/post.md
文件,如下 post.md
markdown 进阶
代办列表:
1
2- [ ] 不勾选
- [x] 勾选显示如下:
- 不勾选
- 勾选
字体编辑:*, _, ~
1
2
3斜体: *斜体* _斜体_
粗体: **粗体** __粗体__
删除线:~~删除线~~显示如下:
斜体: 斜体 斜体
粗体: 粗体 粗体
删除线:删除线插入自定义大小和布局的图片:
<div align="center"><img src="" width="" height=""></div>
align 是怎么布局, height可以不加,给出width后根据原图自动计算。
实例:图片和文字混排:
1
2
3
4
5
6
7<img src="read.jpg" align="right">
这是一个示例图片。
图片显示在 N 段文字的右边。
N 与图片高度有关。
刷屏行。
刷屏行。
到这里应该不会受影响了,本行应该延伸到了图片的正下方,所以我要足够长才能确保不同的屏幕下都看到效果。显示如下:
这是一个示例图片。 图片显示在 N 段文字的右边。 N 与图片高度有关。 刷屏行。 刷屏行。 到这里应该不会受影响了,本行应该延伸到了图片的正下方,所以我要足够长才能确保不同的屏幕下都看到效果。
有效的写作样式
主题自带样式 代码块高亮
先看效果:
1 | /** |
1 | \`\`\` [language] [title] [url] [link-text] |
在 ``` 后面可以添加diff,然后用-,+辨识代码的修改。
自定义自己的顶部文字样式:
1 | // 文章```代码块顶部样式 |
主题自带样式 文本居中引用
源码:
1 | {% cq %} |
效果:
人生乃是一面镜子,
从镜子里认识自己,
我要称之为头等大事,
也只是我们追求的目的!
更多 NexT 主题自带的标签样式,请点击:http://theme-next.iissnan.com/tag-plugins.html
主题自带样式 note标签
源码:
1 | <div class="note default"><p>default</p></div> |
效果:
default
- helloword this is a link : [link](http://theme-next.iissnan.com/tag-plugins.html) `hello` teset **hello**
- test I don't know what I want to say.
success
info
warning
danger
danger no-icon
增强显示效果,在config文件中配置:
1 | # Note tag (bs-callout). |
主题自带样式 label标签
源码:
1 | {% label default@默认 %} |
效果:
默认 主要 颜色 成功 消息 警告 danger自定义样式 引用
在custom.styl中加入了
1 | // 自定义的引用样式 |
实现下面代码:
1 | <blockquote class="question">内容</blockquote> |
效果:
内容
MongoDB存储与查询机制
前言
这篇是 NoSQL数据库技术及其应用研究 的下篇,也是主要引用 NoSQL数据库技术及其应用研究 论文。
存储机制与反范式模式设计
数据模型
逻辑模型:
一个MongoDB系统由多个数据库组成,每个数据库有一组集合(collection) 组成,每个集合由任意个文档(Document)组成,而每个文档由一系列字段(Field)组成,每个字段是一个键值对(key-value pair),其中key是字段的名称,value是对应的属性值,物理模型:
一个数据库在文件中的存储,其中webinfo是数据库名
.ns 文件是命名空间文件,存储的是一个哈希表,存储每个子命名空间的元数据。
.0 等是数据文件,新的数据文件比前一个文件大一倍,最大为2GB。数据文件有多个数据块(extent)组成,数据块由多个数据记录(record)组成。extent和record都是双向链表,record是存储的最小单位,存储BSON格式的数据。
使用GridFS文件系统规范,提供一种透明的机制将一个大文件分割成为多个较小的块对象(chunk)存储。这个还没有理解
存储架构
分为客户端和服务器,在服务器中运行Mongod提供服务,客户端应用程序通过调用 Driver API, 使用Mongo Wire Protocol通讯协议向mongod提交请求并获得应答。
反范式模式设计
关系型数据库的规范化理论提出了1NF, 2NF, 3NF, BCNF, 4NF 的范式概念,基本思想是通过模式分解来逐步消除数据依赖中不合适的部分,使模式中的各关系模式达到某种程度的分离。
具体的范式知识参考:关系型数据库之范式
因为MongoDB允许关系的嵌套和数组元素。意味着MongoDB更喜欢将信息组织在一起,这样在一些场景下增加则信息的聚合度,减少关联操作,同时也是查询变得简单。
但是这样意味着可能的增加冗余信息。
分布式存储机制与应用
MongoDB采用自动分片的分布式集群实现数据的横向扩展,在集群中使用复制集技术保证数据的可靠性。
自动分片机制
MongoDB分片存储体系架构:
分区算法:
MongoDB采用范围分区, 服务器中的分区配置的元数据使用2PC作为一致性算法。复制集技术:
采用半同步主从复制技术,主节点负责执行写操作和强一致性读操作,从节点负责执行最终一致性读操作,修复节点是指节点正在和主节点进行数据同步,结束之后状态变为从节点。从节点监听主节点oplog的更新;若有新的操作,每一个从节点都复制这些操作到自己的oplog,然后根据记录在自己的数据库上执行这些操作;
主节点的重新选举: 机制还是比较简单,不能满足强一致性,只能保证基本没有问题。是从节点主动拉取oplog,还是主节点主动发送消息。我觉得是主节点主动合理。
分片建选择机制:
分区粒度, 写扩展, 查询隔离。
查询机制
主要讲了MongoDB的查询语法和查询优化。还有自己的一点小小的建议。
这不是我关注的重点,以后有机会再补充。