小谈 跳槽

最近看一个帖子《阿里70w vs IBM 40W》， 帖子里面充斥着阿里和IBM 各种出差补助的争吵， 实在无语， 忍不住，利用周末的时间，总结自己的想法， 抛砖引玉一下， 欢迎各位朋友一起探讨。 跳槽其实是一个非常大的话题，可以从梦想，从性格，从经历，从专业等各个维度长篇大论一番，另外每个人都有自己的经历，从而都有自己的解读， 没有哪一种是完全正确的，也没有哪一种是完全错误的，而我只能说，将我的理解表达出来，如果你有更多的想法，不妨也探讨一下。

背景

因为阿里经常进行机房断网演练， 如果一套zk 只能部署在一个机房时， 当发生断网时， 这套zk是无法为其他机房提供zk 服务， 因此需要将单机房zk 升级到多机房zk， 但因为zookeeper是强同步方式， 所有的请求会在内部进行同步， 如果机器之间延迟比较大时， zookeeper 问题会非常多， 因此，这套解决方案前提条件是同城多机房, 并且时延比较小。

这套解决方案也适合， zookeeper 升级扩容和zookeeper 机器替换

在多机房方案中， 常常是3机房， 这个时候，推荐221 的分布模式， 客户端多的机房多部署一台zookeeper

scala 入门初探

本章介绍scala 入门基本知识

概述

scala 就是 将函数式编程和面向对象编程进行融合， 并加入静态类型语言的一种编程语言 是一种运行在jvm上的，可以无缝和java 结合的编程语言

原博客下面文章， 因为godaddy 删除了个人空间，导致5年的博文，毁于一旦，真是吐血三升， 很多美好的回忆，已付之东流。

强烈谴责godaddy, 没有任何责任感， 而且多次投诉godaddy无果。

如果有条件，还是建议在阿里云上购买虚拟机，自建网站

2015年6月1号， Twitter 对外宣讲了他们的Heron系统， 从ppt和论文中，看起来完爆storm。昨天，抽空把论文，仔细读了一遍， 把个人笔记和心得分享一下：

最后总结：

Heron更适合超大规模的机器， 超过1000台机器以上的集群。 在稳定性上有更优异的表现， 在性能上，表现一般甚至稍弱一些，在资源使用上，可以和其他编程框架共享集群资源，但topology级别会更浪费一些资源。

而从应用的角度，应用更偏向于大应用，小应用的话，会多一点点资源浪费， 对于大应用，debug-ability的重要性逐渐提升。 另外对于task的设计， task会走向更重更复杂， 而JStorm的task是向更小更轻量去走。

未来JStorm可以把自动降级策略引入， 通过实现阿里妈妈的ASM， debug-ability应该远超过storm， 不会逊色于Heron， 甚至更强。