实验性操作，建议在虚拟化环境下进行，成功后，把脚本记录下来，再在自己电脑上进行。

必然方便得多，但我建议用 VMware，优点是比 Docker 功能多，缺点是比 Docker 性能低。

1.你有可能是因为甲亢，或者你的激素比别人分泌更旺盛，导致比一般人要更容易动怒。

2.要想不动怒，比较难，因为需要分析清楚整个事件明面和背后的牵连因素，对于你个人来说还需要做到心里有逼数。这很难的。

这玩意很简单，所谓联盟链，说白了，就是把数据库在每一方的服务器里做一个 raid 1 的冗余。

接着，数据读写就按 raid 1 的思路去做：

写数据：一方产生的数据，在每一方的数据库里都存一份；
读数据：需要从每一方的数据库里读取数据，同时检查这份数据是否都存在于每一方，以及每一方的数据是否都相等。

其他的，平时怎么来，现在就怎么来。

1.客服系统的业务有点像火车站售票大厅，单个用户在窗口买票时，无论流量还是 CPU 压力，其实并不大，而且每个业务实例之间的关联度还很低，多买票窗口的并行度非常高。麻烦的地方只有一个，就是新用户进来时，需要排队，同时快速通过负载均衡选一个空闲的窗口进行买票。

2.通过上诉分析，技术选型也就简单了。最重要的是前端排队，要能撑起来 1-2k 的峰值。建议 C++，选择一个轻量级内存数据库模块，来做排队前级，后级就是 java 或 Python 甚至 PHP 做的窗口，数据库用龟速 mysql 都行，流量大时多开几个节点。

程序员行业，与陪家人，其实是一对矛盾，这对矛盾不仅国内有，就连微软也都大量存在，没办法的。

所以，漂亮女友，与好工作，二选一吧。

除非你是官二代或富二代，否则不用想着两头都占。

北方冬天取暖的经济成本其实很低，省城高端小区一个月的采暖费也才 2000 左右，能让全屋平均温度保持在 20 度以上。

然而在南方，特别是接近长江但没有暖气的地方，一个月全屋只开空调的费用已经接近 2000 元，而且空调在极寒天气，对温度最高提升也就几度。这种地方如果要把全屋温度升到十几度以上，必须是全屋地暖 + 房间内对流式电暖气 + 局部石英管取暖器，一个月的电费在 4000 元以上。但这种地区，人均工资才 6000~8000，寒冬一个月的舒适级取暖费的电费就要消耗掉半个月工资，根本不实际。

所以，南方地区，大部分居民实际的冬季取暖现状为，局部取暖+其他靠抖。

这算啥，Flash 时代，一个日本的高手，直接在网页上实现了带 AI 的机器人对战。

在 C#中，给学生数组，按照总分、语文分数、其他分数等字段进行多字段排序，自己写的话会有一堆 for 循环以及后处理，而 lambda 只需要一行：

学生数组.OrderBy(x => x.总分).ThenBy(x => x.语文分数).ThenBy....

这玩意本质是函数语言，和 SQL 的思路很像。如果你熟悉 SQL，你就会发现这玩意在处理数据时，非常好用。

@pence2019 我觉得，你的问题，在软件工程相关书籍里，有比较完整的解释说明。

@lihongjie0209 数据库的负载，与很多因素有关。你发的截图，它这书里，只是针对它自己的环境与业务，给出 mysql 的负载信息而已。这种数据看看就行了，不用太关注。你应该更关注你自己的业务。

理发店，分几种。

第一种是小区店，一般最多 2~3 个坑位。这种很便宜，大概 10 元~20 元就可以理发，只是店面装修很一般。

第二种是在人流高峰地段，或者商业区，或者步行街，有大店子，装修地富丽堂皇，里面的从业者一般自称为老师、艺术总监之类的，这种就会催促你办卡，并且剪个头发费用金贵的。你去的应该是这种。

我建议，只是剪发，去小区店就行了。小区店在美团上一般找不到，导航软件上会有，更多的要靠当地居民打听打听。

这年头，硬盘又不值钱，但数据无价。

为了数据安全，建议 raid 1 + 1 热备盘。

首先，一般情况下，1 楼的回答是对的。其他回答什么无锁都是错的。

其次，你这个业务，存在一个特殊性：R 与 W 都是线程 A，而线程 B 只有 R，这种情况可以参考数据库引擎的做法，使用日志，来解决锁问题。也就是说 A 只操作日志，B 可以直接操作队列，然后使用一个新线程负责处理日志、队列以及线程 B 的关系。但这种东西难度较大，比较有挑战。

数据库结构缺失是啥？

重要数据配置经常导致的 BUG 又是啥？

能举个例子不？

@lihongjie0209

1.业界共识，是虽未以文档告知，但无论是软件开发者，还是用户，都会这么去做的约定俗成。

2.测试主从同步当然至少需要建立两个虚拟机，如果有多台物理机必然更好。

3.测试集群，必然需要用更多的虚拟机甚至物理机。其次，如果当硬件条件都不具备时，不应该硬着头皮上集群。

4.这个问题与 IP ＋端口的定义没任何关系，这只是 mysql 对于业界共识的一种硬编码 bug 而已。如果是按照业界共识去做，就不会踩到这个 bug，仅此而已。

5.Redis 不是纯粹的单线程程序，并且它也并不总是 CPU 密集型问题的解决方案。

6.正规公司，招聘的合格的 DBA 与系统管理员，在配置数据库服务器前，必然会对其负载有准确的预算。如果这种场景下，他们仍然选择让服务器在大部分时间以超低负荷运行，那么他们必然有特殊安排，比如首要目标是稳定，而不是资产利用率。

@charlie21 国外我不了解，但国内就是这种现状。

@levon 那请你逐条解释我说的 5 点，为什么是 [是基于 n 年前的认知] 。