在使用git时我们通常会因为一些特殊的原因或者错误的操作造成需要撤销过去的当前或者过去工作区的某个提交，本篇文章将介绍git提供的四种方法:checkout, revert, reset, clean 解决此问题。

1. checkout

checkout提供了一种安全的机制，用于将当前工作区切换成过去保存的工作区。它包含三个功能:

• 1.checkout branch:
  切换当前分支到指定分支上，这是我们最常用的，用于分支间的切换。另外-b参数可用于创建以当前分支作为基础创建一个新的分支。

  1	git checkout -b branch

• 2.checkout commit
  将当前的工作区状态切换成过去某次commit时的工作区状态。该功能主要用于查看过去某次提交的内容。它背后的逻辑是将HEAD指针指向了过去的COMMIT，并不会对当前commit造成任何影响，如下图所示：
  
  举个例子，假设我们的项目状态如下：

  1 2 3 4 5 6 7

  > git log --oneline b7119f2 Continue doing crazy things 872fa7e Try something crazy a1e8fb5 Make some important changes to hello.py 435b61d Create hello.py 9773e52 Initial import

我们想看看435b61d提交时的工作区数据内容可以使用：

1

git checkout 435b61d

恢复到435b61d提交时的状态后，我们可以查看当时文件，以及做一些测试等工作。当完成我们的检查后，我们用下面命令，恢复当前工作区为最新的状态（这里我们假设处于master分支)。

1

git checkout master

• 3.checkout commit file
  当我们只想查看过去某次提交的一个文件，可以使用上面的命令。此时git将会把当前file更新为过去某次提交的内容，并将其放入staged区中。如果我们想恢复该文件，可以使用下面命令,这时将更新file为最新HEAD的文件。

  1	git checkout HEAD file

Read More

简介

nsq是一个由go编写的简单，高效消息队列，它的最大特点是无第三方依赖和配置简单易于使用。

概要

和传统消息队列一样，它分为两种角色，生产者和消费者。生产者发布消息到指定的话题Topic中。消费者通过管道Channel来订阅话题中数据。每个话题通常被多个管道绑定。多个消费者绑定同样的管道在正常情况下只会接收一份数据。

1

                                                    / metrics-consumer1
                                channel[metrics]   -  metrics-consumer2
                            /
producer -> topic[clicks]   -   channel[spam_analyzer] - spam-consumer
                            \   channel[archive]   -  archive-consumer
                                                    \ archive-consumer2

系统由三个子系统构成：控制服务器nsqlookupd， 数据服务器nsqd 和 管理服务器nsqadmin。

Read More

对于一个开发者，每天都需要执行的一条命令就是ssh，如果能高效使用该命令，不仅能提升工程效率，更重要的是能有一个好的心情，不用每条干着重复无聊的输入密码，host等机械劳动。本篇文章介绍如何通过配置ssh提升我们的效率。

ssh config

ssh配置文件默认放在/etc/ssh/sshd_config和用户目录~/.ssh/config中，它的配置主要包括两个方面，主机配置和选项配置。主机配置顾名思义用于配置我们要登录的主机选项，选项则配置关于ssh连接信息。下文将详细介绍。

主机配置

有时我们需要连接多台服务器查看信息或者执行命令，可能由于配置的不同，每次访问服务器都可能像下面这样：

1

ssh username@host -p port

输入繁琐，且我们需要记忆用户名以及host。 一个记忆host的办法是把它放到/etc/hosts中，但我们仍然需要输入用户名，密码，或者有时候port。
ssh提供了更简便的办法，在config中，可以加入如下配置项：

1

Host    别名
    HostName        主机名
    Port            端口，默认22
    User            用户名
    IdentityFile    密钥文件的路径

IdentifyFile文件通过ssh-keygen生成，这里我们指定它的名称为test，这样会在.ssh目录下生成test.pub文件。
生成后我们将该文件内容复制到对端服务器.ssh/authorized_keys文件即可。
现在假设我们要访问的服务器主机名为test-host.com， 用户名为zheli。
这时我们的配置是这样：

1

Host    test
    HostName        test-host.com
    User            zheli
    IdentifyFile    ~/.ssh/test.pub

配置好后，我们仅需下面方式访问即可，是不是很简单？

Read More

weed-fs是一款由Go语言实现的，基于facebook haystack论文的面向blob的分布式存储系统，部分应用于google内部。该系统具有代码量较少，结构简单，且不包含第三方依赖，易于部署的特点。本文将简单介绍一下这个系统。

特点

• 针对大量小文件的文件系统。
• 中心化设计，架构简单，代码量少，由go编写易于维护。
• 各种粒度的复制级别：包括同步/异步rackaware， datacenter aware的复制等。
• 无单节点故障，Master之间Raft协议保证数据可靠性，节点故障可秒级切换。
• 支持各种级别的数据压缩
• 支持目录结构，记录目录元信息。

设计

设计很大程度上借鉴的facebook的论文:Finding a neddle in the hay stack

系统由两个部分构成：Master和VolumeServer。

Master

Master: 维护Volume的元数据，和VolumeServer的状态

元数据管理

为了限制Master内存使用，它只维护volumeid到VolumeServer的映射关系。 客户端需要自己维护文件到fid的映射，如存放到memcached或者mysql。
关系如下：topology/data_center/rack/data_node/volumes
请求处理方式

每次读写请求都将经过Master，Master为写请求分配fid，为读请求返回fid对应的Volume地址

Read More

   终于有个时间能让自己缓一缓，虽然开始不情愿，但最终还是踏上了一年一度的团队outing的行程。去的地方不远，离杭州大约大约4小时车程，是个海边。4小时说多不多，但也不少，为了打发这个时间带上了几本一直没能来得及的看的书。一本是胡适的《容忍比自由更重要》，一本村上春树的《当我谈跑步的时候我谈些什么》，还一本畅销小说。 之前读过胡适自述，自然首先拿起的是他的书，书的内容多源自他的演讲，时间跨度也较长，从初回国时，满腔热血，为了让知识普及，推广白话文。能明显感受到作者几十年间对事物看法的变化。映像最深的要数。
这不免让我想起

1

给定字符串s,可在其任意位置插入元素，问最少插入多少元素能使得字符串变成回文字符串。
eg: ababda -> 加入子串d于首个a之前，变成adbada，即字符串变成回文。

解法1. 动态规划

1

dp(i, j) 表示子串s[i..j]变成回文串最少的花费
dp(i, j) = 0 if i > j
         = dp(i+1, j-1) if s[i] = s[j]
         = min(dp(i+1, j), dp(i, j-1))+1

时间复杂度O(N*2)
解法2. 问题的转化：最长公共子序列

Read More

GFS

GFS包含两个组件，Master和Chunk Server。 Master负责管理元数据信息，DataServer负责数据文件的存储。

元数据服务器：Master

HDFS采用中心节点Master存储系统的元数据信息。Master维护了文件及chunk命名空间、文件到chunk之间的映射、chunk副本的位置信息。其中chunk副本的位置信息不需要持久化，可以通过ChunkServer汇报获取。

元数据大小

为了减小元数据信息，GFS限制每个文件大小最小为64MB。同时限制每个文件的元数据大小仅为64字节，仅用于存储块对应的ChunkServerID。文件Chunk块的元数据如文件大小、磁盘位移都交由Chunk Server管理。最大限度减小元数据大小。
那么我们可以得到1PB数据的Chunk元信息不超过:
1PB / 64MB * 64 = 1GB
这样保证了内存不会成为GFS的瓶颈

Read More

Apache Kafka是一个由Java开发的分布式发布-订阅消息系统，它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一种快速、可扩展的、设计内在就是分布式的，分区的和可复制的提交日志服务。

Apache Kafka具有良好的扩展性和极高的性能，灵活的订阅数据方式使得它已经成为海量消息处理的标杆。

基本概念

1. 数据的切分
   对于每一个topic的数据，将分成多个数据块存储在系统集群中。
   分块采用主/从的方式保证数据的可靠性。同一时间只有主节点负责用户接收请求，从节点只被动的同步数据。
2. 生产者
   生产者可以根据自己需求将消息发送给指定的topic对应的指定分块，也可随机选择一个分块。
3. 消费者
   Kafka最大的特点是保证消费者处理消息的强时序性。它严格限制了，同一时间一个分块最多只有一个消费者。
   同时也对使用者提出了两个要求：
4. 为了保证系统的并发，需在启动之初，选择好每个topic的分块数量。
5. 对于需要保证时序的多个操作，生产者需要指定同样的分块。

   Read More

   说到研究生的失败，不得不从本科甚至高中的失败算起，我从小就不是个好学生，当然这个词似乎还存在一点褒义，应该说从小自恃清高却又能力不足，还喜欢指手画脚。高中的失利并没有让我清醒，大学专业的从新选择也只让我有了短短一个月的回光返照，我还是一个生活在自己世界中的狭隘小人。

Read More

Tinyurl最初由Twitter提出，其目的是为了减少推文中的字数限制。其后相继被广泛应用于社交网络之中，并在该原始功能的基础上加入了安全、数据统计等功能。由于其被广大用户熟知，且是一个典型的分布式系统方案它成为一个面试中常见的设计题。本文抛砖引玉，站在twitter系统的角度分析一下该系统的实现。

接口

设计系统之前让我们来首先看看TinyUrl系统的功能

1. 给定长url 生成短url。
2. 输入短url返回原始长url。
3. url的安全访问控制
4. url的点击统计。
   5…

其中1，2是系统要解决的关键。

分析

并发

让我们考虑twitter当前的场景，它包含活跃用户1亿，每天发表2贴，1/10有链接，那么每天有2000万个url
写并发量为：20,000,000 / 24 / 60/ 60 = 300
考虑巅峰20倍，tps为6000，很小。
读写比例10：1，qps = 60000，相对较高，考虑到未来扩展需要多个节点。

容量

考虑采用哈希表存储映射关系，短url 64字节，长url256字节，考虑哈希表的开销是本省的两倍,存储两年之内的url映射
(64+256)B 20,000,000365*2 = 5TB
数据规模较大，内存存不下，考虑存储时采用基于K/V的永久化存储。

系统原型

1

      client
        |
      proxy
  /     |    \
node1  node2  node3

Read More