去年那种缺电的情况，就只有买个汽油 /柴油发电机能顶上了。太阳能根本供不起空调，何况家用太阳能算上电池实际上是比汽油 /柴油更不环保的。（不过，住楼里面的城里人，太阳能发电跟汽油发电，应该是都用不上的，这得物业统一搞。）

缺水就真的没办法了。干旱的情况下，包括河水、地下水的所有水源都会减少，只能靠外部支援了。

一般来说，新手程序员不出两年就会知道一个程序往往在不同层使用不同的技术，除非他是纯混子。一般来说，一个有正常语言能力的人，会知道“使用 xx 内核”往往意味着内核外面用得是其他东西，除非……

这东西的重点不是用不用，而是如何管理。不管你用数据库+界面配置字典，还是常量配置字典，还是专用工具配置字典，一旦不妥善管理，一段时间后都不如手写键值对方便。

通常，有 UI 的，code-name 键值对的场景是非常常见的，用数据字典统一管理会更方便点，当然具体上还要看你的需求。“数据字典+后台只保存 code”的好处是便于全局统一管理，但是跟业务的贴合度不一定好，尤其是到了一个 code 不止有 name ，还有其他属性的时候。另外对于静态数据，用硬编码的枚举会更好。

本地大公司没有（就连排头的威科姆、新开普这些，都主要是吃补贴或退税的）。外地大公司的下级部门有不少，但大多属于前员工挂靠，很少有真正的独立部门。做软件外包（靠人脉找二包三包那种）的很多。做非科技公司里面 IT 人员的也不少。当然，上面这些加起来，可能还没做中国移动（中移在线）外包的多。

总体上来说，不是外包，就是花瓶，没事别回来。

@shenxj #29 注意，这个文档中的公式，除号跟乘号优先级相同，不是通常的先乘后除。

@shenxj #29 只交 15 年，等于白给，这里是权威回答，https://m12333.cn/qa/isyw.html 。

这个是改了之后的规则，改之前的规则，15 年那个不清楚，但是缴费基数那个在改之前是没有的，那时候是完完全全的基数越高越傻逼（当然现在这个仍然是基数高了傻，不过傻的轻点了）。

不考虑伦理的纯技术考虑：
1 ，终身制，等效于有效期直到死亡。
2 ，有效期的长度，是受失效可能性和续办成本综合影响的，生效可能性大的有效期短，续办成本高的有效期长。
3 ，至少目前的数据，婚姻的失效可能性很小。
4 ，婚姻的续办成本没有实际数据，但是从首次结婚的成本推算，续办成本会很高。

总结：单纯从技术性上考虑，终身制在目前也是最优解。

养老保险是最低交给 15 年才能享受养老金，不是交够 15 年就不用交了。养老金最重要的是基数部分，这部分只跟当地最低工资和退休时的连续缴费年限有关，只有这个才能跑赢通胀。至于缴纳的总和，那个是分 15 年返还的（不考虑通胀的话要多活 15 年才回本，考虑通胀的话这就是个零头，多活 100 年也回不了本）。

因为通胀的原因，你现在够 15 年，跟退休前 15 年，是不一样的。现在交够 15 年就停，那么到时候的基数就是前 N 年的最低工资，跟没有一样。

上面 16 楼说得对，你这不是入职别的公司做远程工作，而是个人自由职业。你这一年，在国内的工作环境下，只能算待业，只会影响发 offer 的的审批流程，不会影响入职流程的。HR 不在意的是你空挡一年或者接单一年，但你应该没跟他说清楚这是无正式工作的一年，他申请 Offer 的时候填成你正式工作一年（也可能 HR 清楚但为了让 Offer 更能顺利被审批故意填的），然后你入职的时候对不上了。

实际上来说，只要你没用代理入职交社保，在建立上，把这一年就空挡出来就行。在意空档期的早晚也不会要，不在意空档期的就避免了流程上的麻烦。

@morty0 #28 如果是异步处理，那么收到即表示成功，自然是收到就 ack 。但不是所有消息都要异步处理，这个具体要看是啥消息。ack 或者 死信机制，只对同步处理的消息有作用，异步处理的消息，需要有其他机制做异常处理。

1 ，这里支持的，应该只包含银联信用卡，不包含普通银行卡。仅能使用密码的借记卡，和信用卡（贷记卡）的密码功能，是中国特色，国际通用的无实物卡扣款认证方式是“卡号+有效期+cvv 码”（实物卡的是卡本身+签名，芯片卡连签名都不需要）。
2 ，战网亚服是台湾运营，台湾运营方式参照的是老美，而老美的订单处理方式超级复杂，显示订单完成，不一定就真完成了。虚拟物品，很有可能是付款只走个形式，7 天后才实际扣款，到时候要是扣款不成功就收回虚拟物品，如果是确定黑卡的话再额外做封禁处理。

境外支付，信用卡是前提，最好还是 visa 、mastcard 的卡（国内信用卡只分账户不分卡，任何银联信用卡成功之后，都可以随时申请 visa/mastcard 全币种信用卡）

@winglight2016 #25
只需要把监听消息和业务处理在应用内部解开就行了，不要拆成不同应用。监听消息和业务处理放在一个服务中，就只是底层的一个线程和异步线程池，对上层业务逻辑没影响。你要分成两个应用，先不考虑资源浪费问题，业务逻辑就搞复杂了。通常来说，映射转发也就几条规则，处理几十个队列，不管是业务逻辑还是性能上，都不具备独立出去的需要。只有映射转发规则多到需要专门的管理界面的时候，才能考虑独立出去。

关于实例 ID 这部分，这个重点是，消费者必须明确的告知消息中间件两个属性：一共有多少个实例，当前实例区分其他实例的标识（可以简单的只是个序号）。这是业务无关的，只跟运维实例的部署配置有关。配置的内容也不多，只需要消费者多加两个配置项，但是这俩配置项管理起来比较麻烦，因为它们的值不可预定义，只能在部署的时候动态决定，且每次部署都要重新决定。

单纯负载均衡或者随机分配的多实例消费者组的话，理论上是无需理会实例 ID 的。当消息不是自动均衡分配，而是按规则分区分配（比如说 1-5 给实例 1 ，6-10 给实例 2 ）的时候，就必须明确给出实例 ID 了。

我这里参考的是 Spring Cloud Stream （ https://docs.spring.io/spring-cloud-stream/docs/current/reference/html/spring-cloud-stream.html#spring-cloud-stream-overview-partitioning ）。请注意这些规则不是 Spring Cloud Stream 决定的，是消息中间件决定的，Spring Cloud Stream 只是做了上层抽象使其用起来更简单些。

@simonlu9 #17 生产者、消费者、消息中间件之间，只有消息中间件是服务器端需要维持多个连接，生产者、消费者都是客户端，只需要用一个线程维持一条连接，不管有多少消息队列。你把消费者监听消息，跟处理消息这两个阶段混在一起看了，这俩不能放到一个线程上同步搞，不然就算你一个队列一个线程，都要严重阻塞。通常来说，消费者收到消息后，是要把实际处理，再转交给异步执行器（对 Java 来说就是线程池）的，这样只需一个线程负责接受消息，一个执行器（线程池）负责处理消息。
@simonlu9 #18 如果是单纯的随机分配或均衡分配的消费者组的话，应该也是无需给出实例 ID 的。

微服务是跟着业务走，不跟着技术实现方式走的。消息队列消费者，绝大多数情况下，都不对应一种业务（具体的说就是实体、实体表、限界上下文这些），当然不能单独拆成一个服务。

问题 1 ，可以通过配置消费者组进行解决，一个消费者组，同一个消费者只会按调度规则扔给唯一的消费者。RabbitMq 、Kafka 都这只，Spring Cloud Stream 还提供了超简单的实现方式（不过运维要麻烦点，后面说）。

问题 2 ，我没明白你说得是什么，看起来像是系统升级时候的配合问题，这个解决起来稍微麻烦但也不是不能解决。生产者消费者如果不能同时更新，那么消息协议上，就要考虑多版本同时兼容的问题了。

最后说说运维麻烦的地方。多实例的时候，对于接口调用，是不用区分具体哪个示例的，负载均衡机制随便选一个就行了，所以实例无需明确 ID ，随机生成都可以。但是对于消费者组，就不能那么随意了，通常都是要明确给出实例 ID 的，不能随机生成，这会增加部署的麻烦成都。。

如果是一水草酸钙结石，那比石头还硬，碎不了的，碎石只能起到抹掉表层其他成分并顺便帮助挪挪位置的作用，最终还是要靠喝水加蹦跳排到膀胱。结石就两个环节回引起绞痛，通过输尿管中间一个细节，和进入膀胱前那个口。楼主看看彩超结果，是到哪里了，一般结石疼一次过后就到输尿管下端了，如果没有，那你后面还会有一次更痛的机会。注意一般来说，如果医生让你碎石，那就应该结石不大无需手术，都不是啥大问题，多喝水等排出去就行了。

我第一次结石，疼了一次到了输尿管下端就不动了，一年半以后才又折腾了一个月才搞出去。第二次不是一水草酸钙结石，是手捏一下就能碎的那种，结果直到排出去都没疼过。

不值钱的东西随便送。

正式的大礼就别送了。你要知道除了极个别国企外，程序员的领导，就算层层往上推到老板，甚至甲方客户那里，都特么是打工仔，送人家没法回的礼，这是给人添堵。