目前公司用的是 thrift

正常，每个星期也就那么 5、6 天不想上班

@lihongjie0209 别人写好的，猜他意图应该是任务来了不让排队，也不让拒绝，就阻塞在那等待消费，感觉和 SynchronousQueue 有点类似吧，业务场景是做 ETL，提交的任务必须跑不能丢弃。

靠自己是没戏了，等相亲了。。。

ExecutorService 里面的构造的线程的队列是无界的，按照阿里手册上的说法是不推荐直接使用，在并发量不大时我是直接用用这个。。。公司项目里是用 spring 配置的线程池 ThreadPoolTaskExecutor，之前公司有用 ExecutorService，在上面包装了一层加了个 Semaphore，线程数量超过最大值时阻塞不让排队。

死亡笔记 全程无尿点

看业务场景吧，类似提交订单、抢红包这种可以需要‘保证’处理，可以接受延迟处理的请求放 MQ 里等待消费返回信息是没问题的。一些如查询列表的请求把它放队列里保证服务器在能处理该请求意义不大吧，服务器响应不过来直接返回服务繁忙通知用户就好了。
1.你说的稳定是指服务器在繁忙时，请求可以在队列里堆积，不至于像直接调用那样返回失败，这个像上面说的看场景，一些不重要的请求失败就失败了，没必要确保服务端一定处理；
2.rpc 也可以做到负载均衡，例如 SpringCloud 里的 RestTemplate+Ribbon，通过注册中心 eureka 提供的信息做到负载均衡（我也只是看过官网的 demo,生产中并没用过，不知道它可不可以实现根据服务方的健康度做到带权重的负载均衡）；
3.kafka 这种分布式队列就是使用 zookeeper 做协调中心的，消费者、生产者都只需链接 kafka 集群。
以上是我的看法，不知道对不对:)

@Takamine 走 http 也算是 RPC 啊，RPC 可以通过 tcp http 等的方式实现，消息载体可以是 json、xml、二进制等

你是想把 MQ 当做请求的分发器，等于所有请求都先到了 MQ，然后再给服务端消费。以前公司做 ETL 时有个类似的场景，数据抽取转换后先扔到 kafka，每个入库的程序去 kafka 拉取数据存数据库。这种需要数据不丢失的场景下挺合适的，大多业务场景的请求当服务器响应不过来了就丢弃了，把请求持久化保存起来也没用。

这是发生幻读了吧，把数据库隔离级别设置成串行化，也可以用队列在业务层串行化，唯一索引貌似是最方便的。

好了，知道你有女朋友了，下一个

《 java 编程思想》（ Thinking in Java ）--> 《 java 并发编程实战》（电子工业出版社那本）--> 《深入理解 jvm 》
这些书有些年份了但很经典，看完后再查查 jdk 每个版本的变动。其他的再抽空看看设计模式、数据库、网络什么的。

听公司那些做 IM 聊得一般使用一些推送服务，如果自己在程序里实现的话用户把进程杀了他就什么消息都收不到了，华为 oppo vivo 都有自己的手机推送服务，和他们对接就好了，还有些第三方推送 极光推送 什么的。

有买过一瓶风之恋，香味淡淡的那种，别人靠的很近才能闻到，不想解释也简单，直接说洗衣液香味就好。

联通流量挺便宜的， 但自从来了深圳网速就下降的怀疑人生。你找客服说换套餐，换大王卡套餐就好了，1 块钱 1G

知乎老哥常说：穷学 CS，富学金融

别问，问就一步到位大 F

之前也在厦门，上家公司测试工资应该也不怎么高，因为都是非常简单的功能测试，主要是“体力活”，和测试聊天他们也说一年也就把测试这套学的差不多，之后就是重复劳动了。想要提高就必须往自动化、性能这块靠，不然就走管理路线了。