#
一个在线2k的游戏，每秒钟并发都吓死人。传统的hibernate直接插库基本上是不可行的。我就一步步推导出一个无锁的数据库操作。 1. 并发中如何无锁。 一个很简单的思路，把并发转化成为单线程。Java的Disruptor就是一个很好的例子。如果用java的concurrentCollection类去做，原理就是启动一个线程，跑一个Queue，并发的时候，任务压入Queue，线程轮训读取这个Queue，然后一个个顺序执行。 在这个设计模式下，任何并发都会变成了单线程操作，而且速度非常快。现在的node.js, 或者比较普通的ARPG服务端都是这个设计，“大循环”架构。 这样，我们原来的系统就有了2个环境：并发环境 + ”大循环“环境 并发环境就是我们传统的有锁环境，性能低下。 ”大循环“环境是我们使用Disruptor开辟出来的单线程无锁环境，性能强大。 2. ”大循环“环境 中如何提升处理性能。 一旦并发转成单线程，那么其中一个线程一旦出现性能问题，必然整个处理都会放慢。所以在单线程中的任何操作绝对不能涉及到IO处理。那数据库操作怎么办？ 增加缓存。这个思路很简单，直接从内存读取，必然会快。至于写、更新操作，采用类似的思路，把操作提交给一个Queue，然后单独跑一个Thread去一个个获取插库。这样保证了“大循环”中不涉及到IO操作。 问题再次出现： 如果我们的游戏只有个大循环还容易解决，因为里面提供了完美的同步无锁。 但是实际上的游戏环境是并发和“大循环”并存的，即上文的2种环境。那么无论我们怎么设计，必然会发现在缓存这块上要出现锁。 3. 并发与“大循环”如何共处，消除锁？ 我们知道如果在“大循环”中要避免锁操作，那么就用“异步”，把操作交给线程处理。结合这2个特点，我稍微改下数据库架构。 原本的缓存层，必然会存在着锁，例如：public TableCache
{
private HashMap<String, Object> caches = new ConcurrentHashMap<String, Object>();
}
这个结构是必然的了，保证了在并发的环境下能够准确的操作缓存。但是”大循环“却不能直接操作这个缓存进行修改，所以必须启动一个线程去更新缓存，例如： private static final ExecutorService EXECUTOR = Executors.newSingleThreadExecutor();
EXECUTOR.execute(new LatencyProcessor(logs));
class LatencyProcessor implements Runnable
{
public void run()
{
// 这里可以任意的去修改内存数据。采用了异步。
}
}
OK，看起来很漂亮。但是又有个问题出现了。在高速存取的过程中，非常有可能缓存还没有被更新，就被其他请求再次获取，得到了旧的数据。 4. 如何保证并发环境下缓存数据的唯一正确？ 我们知道，如果只有读操作，没有写操作，那么这个行为是不需要加锁的。 我使用这个技巧，在缓存的上层，再加一层缓存，成为”一级缓存“，原来的就自然成为”二级缓存“。有点像CPU了对不？ 一级缓存只能被”大循环“修改，但是可以被并发、”大循环“同时获取，所以是不需要锁的。 当发生数据库变动，分2种情况： 1）并发环境下的数据库变动，我们是允许有锁的存在，所以直接操作二级缓存，没有问题。 2）”大循环“环境下数据库变动，首先我们把变动数据存储在一级缓存，然后交给异步修正二级缓存，修正后删除一级缓存。 这样，无论在哪个环境下读取数据，首先判断一级缓存，没有再判断二级缓存。 这个架构就保证了内存数据的绝对准确。 而且重要的是：我们有了一个高效的无锁空间，去实现我们任意的业务逻辑。 最后，还有一些小技巧提升性能。 1. 既然我们的数据库操作已经被异步处理，那么某个时间，需要插库的数据可能很多，通过对表、主键、操作类型的排序，我们可以删除一些无效操作。例如： a）同一个表同一个主键的多次UPdate，取最后一次。 b）同一个表同一个主键，只要出现Delete，前面所有操作无效。 2. 既然我们要对操作排序，必然会存在一个根据时间排序，如何保证无锁呢？使用 private final static AtomicLong _seq = new AtomicLong(0);
即可保证无锁又全局唯一自增，作为时间序列。
摘要: 正式环境，4台机器+一台定时任务的机器。 服务器是阿里云的ECS， 负载均衡用的是阿里云的SLB， mysql用阿里云的RDS， 缓存用阿里云的OCS， 运维基本上是都不需要担心了， 现在的云服务已经非常完善了， 其实我们用阿里云的服务非常多， 大概有20多个类型的服务， 感谢阿里云。 而我的技术栈是nodejs + mongodb，而阿里云有k-v兼容redis协议的nosql，无mongodb...
阅读全文
#!/bin/bash
#tomcat start script
# ./tomcat_start.sh start|restart|stop
RETVAL=
0start() {
echo -n
"Tomcat Starting
" echo
/root/java/apache-tomcat-
7.0.
47/bin/startup.sh
}
stop() {
echo -n
"Tomcat Stop" echo
" port "$
1 if [ !
"$1" ];then
echo
"Usage port " exit 1 fi
pid=`netstat -tpln|
grep $
1 | awk
'{print $7}' | awk -F/
'{print $1}'`
if [ -n
"$pid" ];then
echo
$pid echo
"kill -9 pid "$pid kill -
9 $pid fi
}
restart() {
echo -n
"Tomcat restart" echo
stop $
1 start
}
case
"$1" in
start)
start;;
stop)
stop
"$2";;
restart)
restart
"$2";;
*)
echo $
"Usage: $0 {start|stop|restart}" exit 1esac
exit $RETVAL
1.Spark生态圈
如下图所示为Spark的整个生态圈，最底层为资源管理器，采用Mesos、Yarn等资源管理集群或者Spark 自带的Standalone模式，底层存储为文件系统或者其他格式的存储系统如HBase。Spark作为计算框架，为上层多种应用提供服务。 Graphx和MLBase提供数据挖掘服务，如图计算和挖掘迭代计算等。Shark提供SQL查询服务，兼容Hive语法，性能比Hive快3-50 倍，BlinkDB是一个通过权衡数据精确度来提升查询晌应时间的交互SQL查询引擎，二者都可作为交互式查询使用。Spark Streaming将流式计算分解成一系列短小的批处理计算，并且提供高可靠和吞吐量服务。
2.Spark基本原理
Spark运行框架如下图所示，首先有集群资源管理服务（Cluster Manager）和运行作业任务的结点（Worker Node），然后就是每个应用的任务控制结点Driver和每个机器节点上有具体任务的执行进程（Executor）。
与MR计算框架相比，Executor有二个优点：一个是多线程来执行具体的任务，而不是像MR那样采用进程模型， 减少了任务的启动开稍。二个是Executor上会有一个BlockManager存储模块，类似于KV系统（内存和磁盘共同作为存储设备），当需要迭代 多轮时，可以将中间过程的数据先放到这个存储系统上，下次需要时直接读该存储上数据，而不需要读写到hdfs等相关的文件系统里，或者在交互式查询场景 下，事先将表Cache到该存储系统上，提高读写IO性能。另外Spark在做Shuffle时，在Groupby，Join等场景下去掉了不必要的 Sort操作，相比于MapReduce只有Map和Reduce二种模式，Spark还提供了更加丰富全面的运算操作如 filter,groupby,join等。
Notes: 在集群(cluster)方式下, Cluster Manager运行在一个jvm进程之中，而worker运行在另一个jvm进程中。在local cluster中，这些jvm进程都在同一台机器中，如果是真正的standalone或Mesos及Yarn集群，worker与master或分布于不同的主机之上。
JOB的生成和运行
job生成的简单流程如下
1.首先应用程序创建SparkContext的实例，如实例为sc
2.利用SparkContext的实例来创建生成RDD
3.经过一连串的transformation操作，原始的RDD转换成为其它类型的RDD
4.当action作用于转换之后RDD时，会调用SparkContext的runJob方法
5.sc.runJob的调用是后面一连串反应的起点，关键性的跃变就发生在此处
调用路径大致如下
1.sc.runJob->dagScheduler.runJob->submitJob
2.DAGScheduler::submitJob会创建JobSummitted的event发送给内嵌类eventProcessActor
3.eventProcessActor在接收到JobSubmmitted之后调用processEvent处理函数
4.job到stage的转换，生成finalStage并提交运行，关键是调用submitStage
5.在submitStage中会计算stage之间的依赖关系，依赖关系分为宽依赖和窄依赖两种
6.如果计算中发现当前的stage没有任何依赖或者所有的依赖都已经准备完毕，则提交task
7.提交task是调用函数submitMissingTasks来完成
8.task真正运行在哪个worker上面是由TaskScheduler来管理，也就是上面的submitMissingTasks会调用TaskScheduler::submitTasks
9.TaskSchedulerImpl中会根据Spark的当前运行模式来创建相应的backend,如果是在单机运行则创建LocalBackend
10.LocalBackend收到TaskSchedulerImpl传递进来的ReceiveOffers事件
11.receiveOffers->executor.launchTask->TaskRunner.run
Spark采用了Scala来编写，在函数表达上Scala有天然的优势，因此在表达复杂的机器学习算法能力比其他 语言更强且简单易懂。提供各种操作函数来建立起RDD的DAG计算模型。把每一个操作都看成构建一个RDD来对待，而RDD则表示的是分布在多台机器上的 数据集合，并且可以带上各种操作函数。如下图所示：
首先从hdfs文件里读取文本内容构建成一个RDD，然后使用filter（）操作来对上次的RDD进行过滤，再使 用map（）操作取得记录的第一个字段，最后将其cache在内存上，后面就可以对之前cache过的数据做其他的操作。整个过程都将形成一个DAG计算 图，每个操作步骤都有容错机制，同时还可以将需要多次使用的数据cache起来，供后续迭代使用.
3.Shark的工作原理
Shark是基于Spark计算框架之上且兼容Hive语法的SQL执行引擎，由于底层的计算采用了Spark，性 能比MapReduce的Hive普遍快2倍以上，如果是纯内存计算的SQL，要快5倍以上，当数据全部load在内存的话，将快10倍以上，因此 Shark可以作为交互式查询应用服务来使用。
上图就是整个Shark的框架图，与其他的SQL引擎相比，除了基于Spark的特性外，Shark是完全兼容Hive的语法，表结构以及UDF函数等，已有的HiveSql可以直接进行迁移至Shark上。
与Hive相比，Shark的特性如下：
1.以在线服务的方式执行任务，避免任务进程的启动和销毁开稍，通常MapReduce里的每个任务都是启动和关闭进程的方式来运行的，而在Shark中，Server运行后，所有的工作节点也随之启动，随后以常驻服务的形式不断的接受Server发来的任务。
2.Groupby和Join操作不需要Sort工作，当数据量内存能装下时，一边接收数据一边执行计算操作。在Hive中，不管任何操作在Map到Reduce的过程都需要对Key进行Sort操作。
3.对于性能要求更高的表，提供分布式Cache系统将表数据事先Cache至内存中，后续的查询将直接访问内存数据，不再需要磁盘开稍。
4.还有很多Spark的特性，如可以采用Torrent来广播变量和小数据，将执行计划直接传送给Task，DAG过程中的中间数据不需要落地到Hdfs文件系统。
Spark的整体流程为：Client 提交应用，Master找到一个Worker启动Driver，Driver向Master或者资源管理器申请资源，之后将应用转化为RDD Graph，再由DAGScheduler将RDD Graph转化为Stage的有向无环图提交给TaskScheduler，由TaskScheduler提交任务给Executor执行。在任务执行的过程中，其他组件协同工作，确保整个应用顺利执行。
Spark架构采用了分布式计算中的Master-Slave模型。Master是对应集群中的含有Master进程的节点（ClusterManager），Slave是集群中含有Worker进程的节点。Master作为整个集群的控制器，负责整个集群的正常运行；Worker相当于是计算节点，接收主节点命令与进行状态汇报；Executor负责任务的执行；Client作为用户的客户端负责提交应用，Driver负责控制一个应用的执行，如图下图：
Spark 框架图
Spark集群部署后，需要在主节点和从节点分别启动Master进程和Worker进程，对整个集群进行控制。在一个Spark应用的执行过程中，Driver和Worker是两个重要角色。Driver 程序是应用逻辑执行的起点，负责作业的调度，即Task任务的分发，而多个Worker用来管理计算节点和创建Executor并行处理任务。在执行阶段，Driver会将Task和Task所依赖的file和jar序列化后传递给对应的Worker机器，同时Executor对相应数据分区的任务进行处理。
Spark的架构中的基本组件介绍：
ClusterManager：在Standalone模式中即为Master（主节点），控制整个集群，监控Worker。在YARN模式中为资源管理器。
Worker：从节点，负责控制计算节点，启动Executor或Driver。在YARN模式中为NodeManager，负责计算节点的控制。
Driver：运行Application的main()函数并创建SparkContext。
Executor：执行器，在worker node上执行任务的组件、用于启动线程池运行任务。每个Application拥有独立的一组Executors。
SparkContext：整个应用的上下文，控制应用的生命周期。
RDD：Spark的基本计算单元，一组RDD可形成执行的有向无环图RDD Graph。
DAG Scheduler：实现将Spark作业分解成一到多个Stage，每个Stage根据RDD的Partition个数决定Task的个数，然后生成相应的Task set放到TaskScheduler中。
TaskScheduler：将任务（Task）分发给Executor执行。
Stage：一个Spark作业一般包含一到多个Stage。
Task：一个Stage包含一到多个Task，通过多个Task实现并行运行的功能。
Transformations：转换(Transformations) (如：map, filter, groupBy, join等)，Transformations操作是Lazy的，也就是说从一个RDD转换生成另一个RDD的操作不是马上执行，Spark在遇到Transformations操作时只会记录需要这样的操作，并不会去执行，需要等到有Actions操作的时候才会真正启动计算过程进行计算。
Actions：操作(Actions) (如：count, collect, save等)，Actions操作会返回结果或把RDD数据写到存储系统中。Actions是触发Spark启动计算的动因。
SparkEnv：线程级别的上下文，存储运行时的重要组件的引用。
SparkEnv内创建并包含如下一些重要组件的引用。
MapOutPutTracker：负责Shuffle元信息的存储。
BroadcastManager：负责广播变量的控制与元信息的存储。
BlockManager：负责存储管理、创建和查找块。
MetricsSystem：监控运行时性能指标信息。
SparkConf：负责存储配置信息。
Spark运行逻辑图
在Spark应用中，整个执行流程在逻辑上会形成有向无环图（DAG）。Action算子触发之后，将所有累积的算子形成一个有向无环图，然后由调度器调度该图上的任务进行运算。Spark的调度方式与MapReduce有所不同。Spark根据RDD之间不同的依赖关系切分形成不同的阶段（Stage），一个阶段包含一系列函数执行流水线。图中的A、B、C、D、E、F分别代表不同的RDD，RDD内的方框代表分区。数据从HDFS输入Spark，形成RDD A和RDD C，RDD C上执行map操作，转换为RDD D， RDD B和 RDD E执行join操作，转换为F，而在B和E连接转化为F的过程中又会执行Shuffle，最后RDD F 通过函数saveAsSequenceFile输出并保存到HDFS或 Hbase中
【习惯】
乞丐到小王家乞讨，他给十块，第二天乞丐又去，又给十块，持续两年。一天只给五块，乞丐：以前给十块，怎么现在给五块？小王：我结婚了。乞丐一巴掌打过去：妈的，你竟拿我的钱去养你老婆？启示：当提供免费服务让客户成为一种习惯，这种服务就不再是优势，而是劣势。
【穷人】
穷人问佛：我为什么这样穷？佛说：你没有学会给予别人。穷人：我一无所有如何给予？佛：一个人一无所有也可以给予别人七种东西。颜施-微笑处事；言施-说赞美安慰的话；心施-敞开心扉对人和蔼；眼施-善义的眼光给予别人；身施-以行动帮助别人；座施-即谦让座位；房施-有容人之心。
【经典故事】
老虎抓到一头鹿后要把它吃掉！鹿说：“你不能吃我！”老虎愣了一下，问：“为什么？”鹿：“因为我是国家二级保护动物！”老虎大笑道：“总不能为了二级保护动物而让一级保护动物饿死吧？！”感悟：时刻保持危机感，不要让自己那点优势害死。
【夫妻】
夫妇逛商场，女的看中一套高档餐具，坚持要买，丈夫嫌贵，不肯掏钱。导购一看，悄悄对丈夫说了句话，他一听马上掏钱。是什么让他立马转变？导购员对丈夫说：“这么贵的餐具，你太太是不会舍得让你洗碗的。”启示：人的观念没有什么不可改变，关键是角度，要善于揣摩客户心理。
【班花】
女生公开投票选班花，相貌平平的小梅发表演说：如我当选，再过几年，在座姐妹可以向自己先生骄傲的说，我上大学时候，比班花还漂亮！结果，她全票当选——启示：说服别人支持你，不一定要证明比别人都优秀，而是让别人觉得,因为有你，他们变得更优秀更有成就感。
【管理的弊端】
女孩买了条裤子，一试太长，请奶奶帮忙剪短，奶奶说忙；找妈妈，也没空；找姐姐，更没空。女孩失望地入睡了。奶奶忙完家务想起小孙女的裤子，就把裤子剪短了一点；姐姐回来又把裤子剪短了；妈妈回来也把裤子剪短了，最后裤子没法穿了。——管理的弊端就在于：要么都不管，要么都来管！
【杯子】
当一只玻璃杯中装满牛奶的时候，人们会说“这是牛奶”；当改装菜油的时候，人们会说“这是菜油”。只有当杯子空置时，人们才看到杯子，说“这是一只杯子”。同样，当我们心中装满成见、财富、权势的时候，就已经不是自己了；人往往热衷拥有很多，却往往难以真正的拥有自己。
【碗破的启示】
一个卖瓷碗的老人挑着扁担在路上走着，突然一个瓷碗掉到地上摔碎了，但是老人头也不回地继续向前走。路人看到觉得很奇怪，便问：“为什么你的碗摔碎了你却不看一下呢？”老人答到：“我再怎么回头看，碗还是碎的。”你得到什么启示呢？
【要害与敏感关键点】
公司在男厕小便池上贴了一纸条：“往前一小步，文明一大步。”结果地上仍有许多尿渍。后来公司认真吸取教训，纸条改成：“尿不到池里说明你短；尿到池外说明你软”，结果地上比以前干净许多。启示：有时扬其长不如揭其短！给客户的提案要具体并准确地切中其要害与敏感关键点才有效。
【个人与团队】
老师问弟子：一滴水如何能不干枯？弟子沉默不语。老师说道：一滴水，风可以将它吹干、土可以把它吸干、太阳可以把它蒸发，要想要不干枯，只有让它融入大海。一个人无力独撑天下，要想获得成功，就得学会与人合作，独木难林，这就是我们常说的：再强大的个人都不如一个团结的组织。
【比耐力】
两只乌龟在田边相对一动不动，老农对一旁的专家说：它们在比耐力，谁先动谁就输了。专家指着一只龟壳上有甲骨文的乌龟说：据我多年研究，这只乌龟已死五千多年了。另一只乌龟伸出头来说：死了也不说一声，害得老子在这里干等。装死的乌龟大笑说：你输了吧，专家的话你也听！
【经验与学历】
一伙劫匪在抢银行时说了句至理名言：“通通不许动，钱是国家的，命是自己的！”劫匪回去后，其中一新来的硕士劫匪说，老大，我们赶快数一下抢了多少，那老劫匪（小学文化）说：“你傻啊？这么多，你要数到什么时候？今天晚上看新闻不就知道吗？”网友微评：这年头工作经验比学历更重要！
【值得思考】
某人买了一坛好酒，放在小院，第二天，酒少了1/5，便在酒桶上贴了不许偷酒四个字。第三天酒又少了2/5，又贴了偷酒者重罚。第四天，酒还是被偷，于是贴尿桶二字，看谁还喝。第五天他哭了。桶满了……故事还没完，第六天，他再次在酒桶上贴了不许偷酒四字。那一天很多人都哭了。
【鹦鹉与乌鸦】
鹦鹉遇到乌鸦，笼中的鹦鹉安逸；野外的乌鸦自由。鹦鹉羡慕乌鸦自由，乌鸦羡慕鹦鹉安逸，二鸟便商议互换。乌鸦得到安逸，但难得主人欢喜，最后抑郁而死；鹦鹉得到自由，但长期安逸，不能独立生存，最终饥饿而死。做最好的自己，不要羡慕他人的幸福，也许那并不适合你。
【顿悟】
老师问：“有个人要烧壶开水，生火到一半时发现柴不够，他该怎么办?”有的同学说赶快去找，有的说去借、去买。老师说：“为什么不把壶里的水倒掉一些？”。同学顿悟，世事总不能万般如意，有舍才有得。人生的许多寻找，不在于千山万水，而在于咫尺之间。
【化妆品】
朋友刚结婚不久，开了家化妆品店，生意好得不得了。有天我去店里玩，见一40多岁的女顾客问小李：“这款化妆品效果怎么样？”小李：“哦，这款我不熟悉。请等一下，我妈帮你介绍。”说着把他老婆拉了过来。顾客直视其老婆足足十分钟，什么也没问就掏出钱包：“买＂。
【营销哲学】
害羞男孩在教室自习，看到一个很中意的女孩，眼看女孩看完书要离开了，害羞的男孩憋红了脸上前搭讪：同学能借我10块钱吃面条吗？钱包丢宿舍了，这是我的学生证，你给我手机号，回头还你钱。女孩想了想说：行吧。正掏钱，男孩又说：要是能借20，我请你也吃一碗。
【琐事】
一只鼬鼠要与一只狮子决战，狮子果断地拒绝了。鼬鼠说：“你害怕了吗？”狮子说：“如果答应你，你就可以得到曾与狮子比武的殊荣；而我呢，以后所有的动物都会耻笑我竟和鼬鼠打架。”不要被不重要的人和事过多打搅，因为成功的秘诀就是抓住目标不放，而不是把时间浪费在无谓的琐事上。
【销售心理】
某富翁娶妻，有三个人选，富翁给了三个女孩各一千元，请她们把房间装满。女孩A买了很多棉花，装满房间的1/2。女孩B买了很多气球，装满房间3/4。女孩C买了蜡烛，让光充满房间。最终，富翁选了胸部最大的那个。这个故事告诉我们：了解客户的真实需求非常重要。
【有效沟通】
两头牛在一起吃草，青牛问黑牛：“喂！你的草是什么味道？”黑牛道：“草莓味！”青牛靠过来吃了一口，愤怒地喊到“你个骗子！”黑牛轻蔑地看他一眼，回道：“我说草没味。”启示：团队合作、管理过程中，能否有效沟通、掌握有效沟通渠道是凝聚竞争力，强化执行力，提升业绩的关键。
美女住酒店一晚
结账时账单800元，她抱怨太贵。经理说这是标准收费，酒店附设泳池、健身房和wifi。美女说自己完全没使用，经理说饭店有提供，是她自己不用。女客人打开皮包掏钱付账，但说要扣除经理和她共度春宵的700元，只拿出100元。经理急呼：“我哪有？”女客人：“我有提供，是你自己不用！”
1、阿里内部的常见级别和定义
P序列=技术岗 M序列=管理岗 (注：样本有限，以下全部数据仅供参考!)
-阿里的非管理岗分为10级，其中P6、P7、P8需求量最大，也是阿里占比最大的级别。前面例子中那位郁闷的同学拿到了P6+的offer，正处于最庞大但又最尴尬的级别中段，至于为什么差一点儿没拿到P7，难道是HR在省招聘费?
2、阿里的级别对应薪资
阿里薪资结构：一般是12+1+3=16薪;年底的奖金为0-6个月薪资，90%人可拿到3个月。除了薪水，股票也是重要的收入之一，阿里的股票分年限行权，一般4年拿完。
说到股票，顺便普及下常识。股票是公司用来奖励员工忠诚度的，所以阿里分年限行权，要离职套现得准备好充足的现金。因为当月薪水和归属股票是一起算作当月个人收入的，所以归属时通常要缴纳高达45%的个税，然后得到的可能还是限制性股票，还不能马上卖呢。等到可以出售的时候，还得缴纳20%股票增值部分的个人所得税。同时，你必须先缴税，才能归属，缴税还必须用现金，不能sell to cover!So，拿的越多，先拿出的cash就越多，这里面的流动性风险你自己权衡吧。
二、百度内部级别和薪资待遇
1、百度的技术级别
百度有4万人，每年招聘应届生技术产品人员1000人左右，技术岗位级别和阿里类似，分为T序列12级，不赘述了，大概阿里的级别减1或2，就是百度的级别。
主要集中在T5/T6，升T7很困难，T7升T8更困难;T7以上一般就不做coding了;一般来说，在百度待3年能给到T5，很多人都等不到三年，原因下面说，社招过来的，一般是外面公司的技术骨干了;T10是技术总监，十个左右;T11是首席科学家;T12基本没见过。
2、百度薪资的大概范围
百度薪资结构：月薪×14.6(12+0.6+2)，其他岗位月薪×14;T5以上为关键岗位，另外有股票、期权;T5、T6占比最大的级别，T8、T9占比最小;级别越高，每档之间的宽幅越大。
百度是一家业务定性，内部稳定，金字塔形的成熟公司。也就是说，大部分事情都是按部就班、驾轻就熟，所有人都比较轻松、稳定、舒服，尤其是对老员工而言。但是对于新员工来说，这意味着成长空间的极度压缩，机会少，上升慢。
百度工资高，福利好，但是这么多年期权已经基本发光了，只有总监以上才有，几十股几百股就算多了。问题就来了，百度新老员工的期权数量太悬殊，据说到百度楼下停车场一看，开卡宴的都是老员工，开捷达的都是新员工，其实很多新员工的贡献比老员工大得多，但是收入反而倒挂，于是很多新人等不到3年就跳了。
三、腾讯的内部级别和薪资待遇
1、腾讯的技术级别
腾讯的分级和阿里/百度都不一样，分为T1/T2/T3/T4共4级，每级又细分为3小级。员工仍然集中在中段，尤其是 T2.3 和 T3.1;想从T2跨到T3，即从2.3升3.1是非常困难的。
2、腾讯的薪酬和级别的关系
腾讯标准薪资是14薪，但是通常能拿到16-20薪;T3.1以上开始另外有股票。值得一提的是，腾讯是有淘汰制考核的。一般一年两次考核(6月、12月)，实行末尾淘汰制，0-10%优秀，必须有5%的人转组(转组也可能出现没人接收的情况)或者被开除。升级也和考核结果很有关系，要升一个小等级，必须最近两次考核得过一次A类考核结果。升T3.1是内部晋升的第一道槛，要求架构在领域内优秀，被追问攻击时能无漏洞应答出来——据说只有30%的通过率。同时，腾讯好的一点在于，底层普通员工如果技术真的不错，照样升级，和是不是leader关系不大。leader的带队价值在T3.3时才显现出来。
来看看BAT级别对照表
结语
各个公司头衔名字都不一样，级别的数目也不一样;有些扁平，有些很多level慢慢升;有些薪水范围严格跟级别挂钩，有些薪水和级别并没有绝对对应的关系。无论你是向往BAT还是身居其中，把握每年的评级机会/跳槽机会，建立一条上升的职业曲线更为重要。因为，没有变化是一件很可怕的事情。
摘要: 这几年，持续集成随着敏捷在国内的推广而持续走热，与之相伴的持续部署也一直备受关注。自前两年，持续交付这个延续性概念又闯进了国内IT圈，慢慢开始在社区和会议中展露头角。许多不明真相的群众跟风哭着喊着要“上”，而许多前CI的半吊子玩家换件衣服就接着干，有的甚至衣服都来不及换……国内的这些土财主如果不巧请了某些所谓的战略家，除了建了一堆持续集成环境，以及每天嚷嚷着要这个要那个，混乱的状况在根本上没有得到改善。本文无意费力探讨持续集成和持续交付的概念，而是打算谈谈对于大型软件企业，以持续集成为基础实现持续部署（交付）时，所要面对的问题以及可行的解决方案。地主老财们，夜黑风正猛，山高路又远，注意脚下……
阅读全文