Posted on | In

查询系统相关信息

$ cat /etc/centos-release
CentOS release 6.7 (Final)

[root@host ~]# uname -i
i386

安装gcc4.8

centos 6 的gcc版本太低才4.4.7, 要安装高版本的4.8才完全支持c++11

. . .

Posted on | In

在了解一致性哈希算法之前，最好先了解一下缓存中的一个应用场景，了解了这个应用场景之后，再来理解一致性哈希算法，就容易多了，也更能体现出一致性哈希算法的优点，那么，我们先来描述一下这个经典的分布式缓存的应用场景。

场景描述

假设，我们有三台缓存服务器，用于缓存图片，我们为这三台缓存服务器编号为0号、1号、2号，现在，有3万张图片需要缓存，我们希望这些图片被均匀的缓存到这3台服务器上，以便它们能够分摊缓存的压力。也就是说，我们希望每台服务器能够缓存1万张左右的图片，那么，我们应该怎样做呢？如果我们没有任何规律的将3万张图片平均的缓存在3台服务器上，可以满足我们的要求吗？可以！但是如果这样做，当我们需要访问某个缓存项时，则需要遍历3台缓存服务器，从3万个缓存项中找到我们需要访问的缓存，遍历的过程效率太低，时间太长，当我们找到需要访问的缓存项时，时长可能是不能被接收的，也就失去了缓存的意义，缓存的目的就是提高速度，改善用户体验，减轻后端服务器压力，如果每次访问一个缓存项都需要遍历所有缓存服务器的所有缓存项，想想就觉得很累，那么，我们该怎么办呢？原始的做法是对缓存项的键进行哈希，将hash后的结果对缓存服务器的数量进行取模操作，通过取模后的结果，决定缓存项将会缓存在哪一台服务器上，这样说可能不太容易理解，我们举例说明，仍然以刚才描述的场景为例，假设我们使用图片名称作为访问图片的key，假设图片名称是不重复的，那么，我们可以使用如下公式，计算出图片应该存放在哪台服务器上。

hash（图片名称）% N

. . .

Posted on | In

A optimized hexo-theme-next

一个优化过的NexT主题.

我修改了很多NexT的代码来对原版 NexT 做了优化, 如下 :

  • 改了NexT的很多地方来优化移动端的表现
    • header的布局
    • 移动端和PC端的侧边栏更加统一
    • 移动端的文章目录列表现在可以滑动了
  • 添加了文章加密的支持
  • 升级到了fancybox3并完成适配, 3更流畅且拥有更多效果
  • 重做了本地搜索引擎
    • 现在移动端不会经常无故弹不出键盘了
    • 也不会列出加密文章的内容了
    • 更优雅的过渡动画
  • 添加了headroom支持, 现在有一个可以会自动隐藏的header了, 往下滚一下鼠标则隐藏, 往上则出现

Live Preview

My Blog

Usage

0. 点击这里下载nvm-setup.zip, 解压并安装nvm之后, nvm install 10.13.0 然后再 nvm use 10.13.0则安装了node.js的10.13.0的版本, 尝试node -v和nvm ls看看版本, 这个node版本很关键, 不要乱改

1. Delete my source folder
删除我项目中的 source 文件夹

2. Create a new source folder
新建一个 source 文件夹

2.5. npm install -g hexo-cli然后再npm install --force

3. Unzip my_node_modules.tar.gz to the current directory: tar -zxvf my_node_modules.tar.gz
解压 my_node_modules.tar.gz 到当前目录(确保这一步在安装了hexo之后): tar -zxvf my_node_modules.tar.gz

4. Learn Hexo’s base usage for Writing/Generating/Deployment
学习Hexo的基本操作来写作/生成/部署

5. Learn NexT
学习 NexT

6. Modify /_config.yml & /themes/next/_config.yml
修改 /_config.yml 和 /themes/next/_config.yml

7. hexo clean删除缓存

8. hexo generate生成静态文件

9. hexo server启动一个本地hexo服务器

Posted on | In

Actor模型介绍

Actor模式是一种并发模型，与另一种模型共享内存完全相反，Actor模型share nothing。所有的线程(或进程)通过消息传递的方式进行合作，这些线程(或进程)称为Actor。共享内存更适合单机多核的并发编程，而且共享带来的问题很多，编程也困难。

随着多核时代和分布式系统的到来，共享模型已经不太适合并发编程，因此几十年前就已经出现的Actor模型又重新受到了人们的重视。MapReduce就是一种典型的Actor模式，而在语言级对Actor支持的编程语言Erlang又重新火了起来，Scala也提供了Actor，但是并不是在语言层面支持，Java也有第三方的Actor包，Go语言channel机制也是一种类Actor模型。

Actor的基础就是消息传递, Actor由状态(state)、行为(Behavior)和邮箱(mailBox)三部分组成 :

  • 状态(state)：Actor中的状态指的是Actor对象的变量信息，状态由Actor自己管理，避免了并发环境下的锁和内存原子性等问题
  • 行为(Behavior)：行为指定的是Actor中计算逻辑，通过Actor接收到消息来改变Actor的状态
  • 邮箱(mailBox)：邮箱是Actor和Actor之间的通信桥梁，邮箱内部通过FIFO消息队列来存储发送方Actor消息，接受方Actor从邮箱队列中获取消息

. . .