发表于 | 分类于 ，

当了好几年码工了，用得最多的IDE是VS，主要是配合助手实在是太强大了，偶尔也用用vim，eclipse，cb等工具，一直都觉得vs没有一个可以导入文件系统的方式创建工程很坑爹，这两天和同事交流才发现是自己一直都没有注意，vs(除了6)系列一直都有，且看下图(wordpress不能显示中文文件名的图？)：
vs_create_prj_from_folder

发表于 | 分类于

由于最近工作代码量不会太多，打算用vim搞定，刚好弥补下之前vim囫囵吞枣式的使用习惯。

  • ctags -R –languages=c,c++ .会生成一个tags文件，打开vim通过set tags=tags;命令设置tags文件路径，开始的tags表示会从当前目录找tags文件，分号后面可以再加其他可选的tags文件，ctrl+]在实现和定义之间跳转，ctrl+t回到上一个动作。
  • Texplore这个命令可以在打开tab页时浏览文件夹，很方便的打开多个文件，剩下的就可以通过tab*命令切换tab页了
  • %进行括号匹配跳转
  • 可视化模型下，<,>分别进行减少，增加缩进
  • set encoding设置文件在终端上面显示的编码
  • set fileencoding设置文件写入磁盘的编码

发表于 | 分类于

原文链接：http://blog.csdn.net/huang_xw/article/details/7957908

团队技术博客

发表于 | 分类于

代码中引用了libhdfs，在Hadoop集群负载过高或者某个datanode掉线死极易导致进程挂起，从堆栈可以看出是挂在了pthread_cond_timedwait上面而且是在libjvm.so附近，在https://svn.apache.org/repos/asf/hadoop/common/branches/HDFS-326/CHANGES.txt中有提到修复了一个deadlock的bug。

在目前这种过渡阶段也没有想到很好的办法去验证并修复这个问题，下面是我采取的一个简单方法，在程序中定时去touch一个文件，另外一个监控脚本去stat该文件的修改时间，如果时间超过一定范围即认为死锁了，kill -9然后拉起。但是在某些时候进程负载较高时会导致定时器没有被触发，这时监控脚本就会产生误杀现象。为了解决这个误杀，我又自作聪明的开了一个线程专门去定时touch文件，没过多久死锁现象又出现了，但是进程却没被kill，跟一个同事讨论后才意识到自己犯了一个很荒唐的错误，这里的死锁只是线程级别的!!!

后来另一同事共享了他的方案，通过pstack查看线程堆栈，如果一段时间内堆栈没有发生改变，那么进程基本上是死锁了，感觉这个方法也不错，但是程序中如果有多个线程也不太凑效。

发表于 | 分类于

1修改/etc/resolv.conf，添加对应的nameserver和domain

2修改/etc/nsswitch.conf，找到hosts，在后面添加dns，即hosts: files dns，表示先从/etc/hosts文件查找，再通过dns查找

3重启dns cache进程nscd，否则可能会出现域名可以解析，但是ping不通

发表于 | 分类于

“All TCP servers should specify this socket option to allow the server to be restarted in this situation.”

最近为了提高机器利用率，将原来一台机器部署一个进程改为部署两个进程，考虑到运维的成本，就简单修改可以自动尝试新的端口，当时觉得这个只会在第二个进程启动时会出现。新版本发布没多久，通过网管系统发现异常了，到机器上一看，发现本该监听10086,10087两个端口的，结果变成了10088,10089，这尼玛肿么回事。通过监控脚本日志发现进程重启过了，按理说进程重启这端口还是不会变啊，查看运行日志发现进程重启时10086,10087都被占用了，通过netstat看到在10086上面有TIME_WAIT的链接，行家一眼就看出问题了，这尼玛不就是没设SO_REUSEADDR么，是的确实是通过设置了这个选项就搞定了。

这里顺便说下为啥端口变了就导致服务不可用，因为对外服务时是直接给的服务的指定端口，要是有一个配置中心之类的服务而不是直接暴露服务会更好些，这样就无所谓你端口变不变了，反正对外是透明的。

另外进程重启是因为在某些时刻进程负载过高导致定时器没有触发，间接导致监控脚本认为进程僵死而将其kill掉，这一点目前也修复了。

之前单进程部署时进程有时也会有重启现象，但是由于是非10086端口不可，因此在2MSL时间过后进程还是可以顺利启动的，当然之前没有防止进程僵死的监控，进程重启的概率非常小。

总结几点：

1UNP不仔细看完并实践，真不能写出健壮的网络程序

2当服务需要横向扩展时，提供一个类似配置中心的角色是必须的

发表于 | 分类于

看了一些架构相关的资料，在讲非功能性需求时大部分都会提到以下几个词：
Reliability(可靠性)
Availability(可用性)
Scalability(伸缩性)，包括水平和垂直两类，水平是指通过添加机器提高伸缩能力，垂直是指通过增加单机的硬件配置提高伸缩能力，显然单机的硬件配置是有上限的，因此水平伸缩才是王道。要做到水平伸缩可以通过以下方式进行：

  • Load Balancing(负载均衡)
  • Caching(缓存)
  • Off-Line Processing(离线处理)，也可以认为是异步处理，
  • Partition by Function(按功能切分)这一点有点像公司那门海量课程<大系统小做>，数据层也可以按这个方式进行分离，比如典型的分库分表。
    Resiliency(弹性)

发表于 | 分类于

mongodb分片配置包括以下几个角色：

1configsvr，顾名思义就是存储配置的，这里的配置包括集群中的shareds，databases，collections等，

2shard，存放实际数据的进程

3mongos，路由进程

configsvr其实就是对应的mongod –configsvr，shard其实就是mongod –shardsvr

这里我搭建一个windows最简单的分片集群，所有进程都部署在同一台机器上。

依次执行如下命令，所以的dbpath可以随意指定，但是需要提前创建好:

binmongod –configsvr –dbpath data-config –journal –rest

binmongos –configdb 127.0.0.1:27019

正常启动后配置服务器会创建一个叫做”config”的数据库，包括如下集合：

 

其中databases表示当前集群中的数据库信息，mongos即路由进程，shards目前还没有。

接着启动shard，依次执行如下命令，启动两个shards。

binmongod –shardsvr –dbpath data-shard1 –port 10086 –journal –rest

binmongod –shardsvr –dbpath data-shard2 –port 10096 –journal –rest

不出意外所以进程都会顺利启动，这时一个简答的分片集群就完成了一半了，剩下的就是将shards加入集群，这需要通过mongo shell来完成。

启动binmongo 127.0.0.1:27017/admin，这里ip:port是mongs的，admin是默认的管理数据库，执行如下命令：

sh.addShard(“127.0.0.1:10086”)

sh.addShard(“127.0.0.1:10096”)

此时config数据库中的shards集合数变为2，文档内容如下：

 

至此一个简单的分片集群即搭建完毕，接下来往里面搞点数据。

  • 指定可以分片的数据库
  • 指定可分片的集合
  • 插入数据
    sh.enableSharding(“billowqiu”)，表示”billowqiu”这个数据库需要分片；

sh.shardCollection(“billowqiu.education”, {“date”:1})，表示eduction这个集合按照{“date”:1}的shard-key方式进行分片，这里的shard-key是必须要的，关于shard-key-pattern的详细信息可以去mongo官网查看。

插入数据的方式和普通模式类似，唯一需要注意的是插入时必须带上shard-key，例如

use billowqiu

col=db[“education”]

col.insert({“date”:1997} ,{“name”:”taer mid school”})

col.insert({“date”:2000} ,{“name”:”huangpi three high school”})

总的来说，mongodb配置和使用都是比较容易上手的，其分片模型和许多Master-Slave模式类似，只不过多了一个configsvr的角色，像gfs，bigtable中这些分布式系统中master的角色其实包括了config和mongos。