一、需求分析

需求分析是指开发人员要进行细致的调查分析，准确理解用户的要求。将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的形式功能的过程

1、需求分析的基本原则

• 可以把一个复杂问题按功能进行分解并可逐层细化。
  
• 必须能够表达和理解问题的数据领域和功能领域。
  
• 建立模型。

ModSecurity是一个免费、开源的Web（apache、nginx、IIS）模块，可以充当Web应用防火墙（WAF:Web Application Firewall）。ModSecurity是一个入侵探测与阻止的引擎.它主要是用于Web应用程序所以也可以叫做Web应用程序防火墙.ModSecurity的目的是为增强Web应用程序的安全性和保护Web应用程序避免遭受来自已知与未知的攻击
OWASP是一个安全社区，开发和维护着一套免费的应用程序保护规则，这就是所谓OWASP的ModSecurity的核心规则集（即CRS）。ModSecurity之所以强大就在于OWASP提供的规则，可以根据自己的需求选择不同的规则，当然ModSecurity还有商用的规则
目前ModSecurity正在测试环境测试使用，以下操作是在nginx下添加modsecurity模块来实现WAF的安装配置步骤,

综合利用Nagios、Ganglia和Splunk搭建起的云计算平台监控体系，具备错误报警、性能调优、问题追踪和自动生成运维报表的功能。有了这套系统，就可轻松管理Hadoop/HBase云计算平台。
云计算早已不是停留在概念阶段了，各大公司都购买了大量的机器，开始正式的部署和运营。而动辄上百台的性能强劲的服务器，为运营管理带来了巨大的挑战。

• 如果没有方便的监控报警平台，对于管理员而言犹如噩梦，每天都将如救火队员一样，飞快地敲击键盘，用原始的Unix命令在多台机器中疲于奔命。
  
• 如果没有好的日志管理平台，对于开发者Troubleshooting更是一件泪流满面的事情。
  而如果你是运维团队的总负责人，简洁清晰的Report则非常重要。Stakeholder们动不动就可能问起系统的SLA、机器的利用率等诸多问题，毕竟，公司为此投入了巨大的资金和人力。
  朋友们，当我们管理起公司寄予厚望的云计算平台时，当我们面对如此多充满挑战的实际问题时，该怎么办？
  
  阅读全文 »

1、加盐

生成一个随机数，我们称之为salt，然后在数据库中记录salt和h=hash(pwd + salt)，查询的时候，得到用户的口令p，然后从数据库中查出salt，计算hash(p+salt)，看是不是等于h，等于就是对的，不等于就是不对的。
单纯使用MD5之所以不好，并不是说MD5这种方法容易遭到破解，而事实上对于MD5求原象或者第二原象，也就是“逆计算”这种破解，没有什么很好的方法。只能通过预先计算知道许多MD5的对应关系，存在数据库中，然后使用的时候反查，例如我知道’password’的MD5值是5f4dcc3b5aa765d61d8327deb882cf99，那么我就用一个数据库存起来，只要我看到5f4dcc3b5aa765d61d8327deb882cf99，我就知道这个是口令’password‘使用MD5处理之后的值，原来的口令就是’password’。MD5在身份鉴别系统中用于口令保护已经是很久了事情了，大部分黑客也有针对这种Hash方式准备相应的数据库进行反查，这种数据库称为彩虹表。

在经济学和商业决策制定过程中，会用到“沉没成本（Sunk Cost）”（或称沉淀成本或既定成本）的概念，代指已经付出且不可收回的成本。沉没成本常用来和可变成本作比较，可变成本可以被改变，而沉没成本则不能被改变。在微观经济学理论中，做决策时仅需要考虑可变成本。如果同时考虑到沉没成本（这被微观经济学理论认为是错误的），那结论就不是纯粹基于事物的价值作出的。
举例来说，如果你预订了一张电影票，已经付了票款且假设不能退票。此时你付的价钱已经不能收回，就算你不看电影钱也收不回来，电影票的价钱算作你的沉没成本。
当然有时候沉没成本只是价格的一部分。比方说你买了一辆自行车，然后骑了几天低价在二手市场卖出。此时原价和你的卖出价中间的差价就是你的沉没成本。而且这种情况下，沉没成本随时间而改变，你留着那辆自行车骑的时间越长，一般来说你的卖出价会越低（折旧）。
多数经济学家们认为，如果你是理性的，那就不该在做决策时考虑沉没成本。比如在前面提到的看电影的例子中，会有两种可能结果：
1、付钱后发觉电影不好看，但忍受着看完；
2、付钱后发觉电影不好看，退场去做别的事情。
两种情况下你都已经付钱，所以应该不考虑这件事情。如果你后悔买票了，那么你当前的决定应该是基于你是否想继续看这部电影，而不是你为这部电影付了多少钱。此时的决定不应该考虑到买票的事，而应该以看免费电影的心态来作判断。经济学家们往往建议选择后者，这样你只是花了点冤枉钱，还可以通过腾出时间来做其他更有意义的事来降低机会成本，而选择前者你还要继续受冤枉罪。这就是生活或者投资的智慧！**

一、查看系统负荷

如果你的电脑很慢，你或许想查看一下，它的工作量是否太大了。
在Linux系统中，我们一般使用uptime命令查看（w命令和top命令也行）。（另外，它们在苹果公司的Mac电脑上也适用。）
你在终端窗口键入uptime，系统会返回一行信息。

这行信息的后半部分，显示"load average"，它的意思是"系统的平均负荷"，里面有三个数字，我们可以从中判断系统负荷是大还是小。

1.FIFO算法

　　FIFO（First in First out），先进先出。其实在操作系统的设计理念中很多地方都利用到了先进先出的思想，比如作业调度（先来先服务），为什么这个原则在很多地方都会用到呢？因为这个原则简单、且符合人们的惯性思维，具备公平性，并且实现起来简单，直接使用数据结构中的队列即可实现。
　　在FIFO Cache设计中，核心原则就是：如果一个数据最先进入缓存中，则应该最早淘汰掉。也就是说，当缓存满的时候，应当把最先进入缓存的数据给淘汰掉。在FIFO Cache中应该支持以下操作;

在hexo github 的issue里找到了解决办法,解决Hexo置顶问题，只需两步：

1. 用文章中的js代码替换node_modules/hexo-generator-index/lib/generator.js (见下文代码段)
2. 在需要置顶的文章的front-matter中添加top值，值越大越置顶。

1
2
3
4
5

title: 某某文章
date: 
tags:
categories: 
top: 1000

在同样的教材、同样的老师授课的情况下，影响学生学习成绩的因素主要有两个方面，一是智商，二是习惯。

讲LSM树之前，需要提下三种基本的存储引擎，这样才能清楚LSM树的由来：

1、哈希存储引擎

是哈希表的持久化实现，支持增、删、改以及随机读取操作，但不支持顺序扫描，对应的存储系统为key-value存储系统。对于key-value的插入以及查询，哈希表的复杂度都是O(1)，明显比树的操作O(n)快,如果不需要有序的遍历数据，哈希表就是your Mr.Right

2、B树存储引擎

是B树的持久化实现，不仅支持单条记录的增、删、读、改操作，还支持顺序扫描（B+树的叶子节点之间的指针），对应的存储系统就是关系数据库（Mysql等）。

3、LSM树（Log-Structured Merge Tree）存储引擎

和B树存储引擎一样，同样支持增、删、读、改、顺序扫描操作。而且通过批量存储技术规避磁盘随机写入问题。当然凡事有利有弊，LSM树和B+树相比，LSM树牺牲了部分读性能，用来大幅提高写性能。
通过以上的分析，应该知道LSM树的由来了，LSM树的设计思想非常朴素：将对数据的修改增量保持在内存中，达到指定的大小限制后将这些修改操作批量写入磁盘，不过读取的时候稍微麻烦，需要合并磁盘中历史数据和内存中最近修改操作，所以写入性能大大提升，读取时可能需要先看是否命中内存，否则需要访问较多的磁盘文件。极端的说，基于LSM树实现的HBase的写性能比Mysql高了一个数量级，读性能低了一个数量级。
LSM树原理把一棵大树拆分成N棵小树，它首先写入内存中，随着小树越来越大，内存中的小树会flush到磁盘中，磁盘中的树定期可以做merge操作，合并成一棵大树，以优化读性能。

4、HBase存储的设计主要思想

因为小树先写到内存中，为了防止内存数据丢失，写内存的同时需要暂时持久化到磁盘，对应了HBase的MemStore和HLog
MemStore上的树达到一定大小之后，需要flush到HRegion磁盘中（一般是Hadoop DataNode），这样MemStore就变成了DataNode上的磁盘文件StoreFile，定期HRegionServer对DataNode的数据做merge操作，彻底删除无效空间，多棵小树在这个时机合并成大树，来增强读性能。