某负责搜索的，离职一年多的表示原因太多了。
技术上，据说用上了 SolrCloud ， LVS 等等。但出现过 VIP 配置错误， SC 优化不当的传闻。二、传闻内部 MQ 不再做可靠保障，无法实现增量更新，改用了全量更新。三，我定制的分词器废弃，改用 IK 。以上都是传闻。

本质问题是，团队变更稍微有点经常，导致人员一直是新人，不知道 Ac 业务有什么特异性。其他的内部爆料撕 B 都是传闻，缺少事实依据，官方必然不会承认，个人也不能确定真实性。所以除了人员变更有点频繁外。你看到的都是一堆废话。
最后我甩完锅了。希望 HR 们不要拿 Ac 技术手上都是炸，天天爆炸来压低薪水。（（

HR 么

前略，天国的年终奖

安安静静地围观下

@yaoyi 看官网是个翻译网站。可否介绍下有什么好玩的。在外面飘累了的话 ，可以考虑回家哈哈哈。

卧槽，老家的！可惜我是 Python

@codehehe 卧槽，好棒

@codehehe 真调皮

技术没问题，但英语不行 ，じゃねー

http://society.cnr.cn/news/20151228/t20151228_520949552_1.html
我觉得差不多

但 快播还说有罪的，监管不利的帽子还是要扣的。比如儿童色情，如果你给 YouTube 上传儿童色情，我不信 Google 不会不处理， YouTube 人工审核的负面新闻可不少，如果必要的话 Google 估计还会主动向警方提供上传视频的相关人员的信息。
作为一个企业，要承担必要的社会责任，被政府强制要求也好，还说主动提出也好，这都是基本的责任。快播自己内部的 110 系统就是一个交代，然而这只是面子工程。快播很像中国早期的视频网站，土豆很早的时候，热门排行榜的视频，可以轻易找到色情内容，甚至儿童色情。现在呢？不说绝对没有，至少大部分明面上的都消失了，也积极配合消除不良视频。
然而，快播则没有，还形成社会现象，安装快播几乎等于看色情内容的必要工具，这就是国家要整治它的理由。名头可以很多，题主说的传播如果不算的话，监管不利也可以挂上去。

public static synchronized Singleton getInstance(){ 取方法的时候上锁。。。。这效率要多低啊。。。合理的上锁模式是 实例化的时候上锁 防止重复实例。

es 的话 有 地理索引了，可以画奇怪的图案。
5T 的话 有点纠结。最好分库处理下，时间尺度＋空间尺度，比如一个城市一个库。

NoSQL 的话 还有 MongoDB ， 5T 的量的话，有上集群了，分片＋副本，还要根据时间和空间 再做下划分。读有什么额外的要求吗。

if acquire_lock():
try:
xuxu()
finally:
release_lock()

迅雷+1

放心，如果是讨债公司上门，就是全公司或者全小区知道你欠钱不还了

问题表述 有问题。没有足够的上下文，客服这样回答很正常。这和 App 闪退就去骂开发，不说操作步骤一样，没意义。