庄周梦蝶

生活、程序、未来

声明:本博客所有文章,未经允许,禁止转载。谢谢。

新版delicious上线遇到的几个教训

| Comments

重新设计的delicious.com已经上线,好坏评价都有,俺不参与。 这次上线遇到几个问题,我感觉值得小小总结下,给自己提个醒,以后不能犯这样的错误。

首先是,容量规划很重要。我们的后端系统严重依赖zookeeper集群,但是zookeeper集群只有3台。我们都知道zookeeper可用的前提是过半的node是正常work的,那么3台机器只允许当掉一台,5台机器就允许当掉两台,以此类推。因此通常会推荐将zookeeper的集群设置为奇数台,因此如果希望能在当掉N台机器仍然保证集群可用,那就必须部署一个2N+1的集群。Delicious.com这个zk集群可能是临时搭建的,并没有考虑到容灾的情况,不过3台至少还是能保证一定程度的稳定性,更大的问题在于我们的机器配置用的还是AWS的micro机型,512M内存的机器,导致每个zookeeper的JVM不能开更大的内存(后面我们还发现原来连JVM参数都没有设置,用的还是默认的堆大小),在后续服务陆续添加后,导致zookeeper的压力很大,full gc非常频繁,从而导致client connection频繁超时断开,恶性循环下,整个服务几乎不可用。而后台服务不可用的后果,就是整个网站的可用性也没有了。用户怨声载道。 最终,我们还是不得不临时扩容,增加zookeeper集群到5台,并且将机器型号升级到更大内存和硬盘。目前zookeeper 3.4的升级还不支持热部署,只有通过停机维护来实现。整个过程还由于其他一些意外因素拖延了更久。这个过程给我的教训就是,上线前最好对各个系统有个大概的评估,不能简单地信赖别人,如果稍微注意下zookeeper集群的机器型号等信息,也许我们不会犯下这么低级的错误。

其次一个严重的问题是代码上的BUG,现象是访问个人的profile页面,却看到别人的信息。聪明点的开发者肯定能猜到原因是什么,我这里卖个关子。像这样的BUG,我想主要是因为新系统的开发者对某些信息做了先入为主的假设,没有调查遗留代码而是为了简便就做出决定。也给我提个醒,在做老系统的迁移过程中,要特别注意遗留代码的逻辑和模型,而不是想当然。

其他一些问题,不好在这里讨论,不过我想,应该改变自己的心态,抱怨问题是没有用的,还是要行动起来,做一些力所能及的工作。

PS. Delicious.com的Solr升级到Solr 4.0 Cloud,一个月运行下来还是很稳定的。并且Solr Cloud可以容忍zookeeper集群的意外当机,保留上一次稳定的状态,在这次故障中,表现出乎意料的好。

声明:本博客所有文章,未经允许,禁止转载。谢谢。

工程, 编程

« 发布xmemcached 1.3.9 发布MetaQ 1.4.4 »