副本集群是一组维护相同数据集的mongod实例。一个副本集包含几个承载数据的节点和一个可选的仲裁节点。在承载数据的节点中，只有一个节点被认为是主节点，其他节点被认为是次节点。
主节点接收所有的写操作，次节点接收主节点的操作应用在自己的数据集上，副本节点只是做一个备份的作用，当主节点出现故障时，会自动选出新的主节点。
本教程描述的是包含三个节点的副本集群搭建，所有节点都没有开启访问控制。
因为集群需要通过选举来确定master节点，为了选举不会出现问题，所以集群成员数量应该总是奇数个。
MongoDb版本是`5.0`。
### 1、启动成员节点
测...
### 概述
复制即主从(master-replica)，读写分离。
**运行机制：**
1、主副本连接良好的情况下，主节点会把所有改动通过发送命令流的方式同步到副本节点。
包括客户端写，key过期或者淘汰，和其他在主节点的改动。
2、连接出现问题时，副本节点会尝试重新连接，并且会尝试重新同步连接异常期间丢失的数据。
3、如果同步丢失的数据失败，副本会要求同步完整数据，这个就需要主节点快照整个数据集，再发送到副本节点，之后才会接着正常同步。
默认使用低延时高性能的异步复制模式，适用于大多数Redis用例。副本实例会用异步ACK的方式把自己收到的数据量通告给主节点，所以主节点不需要等待副本节点执行完命令。
客户端可以用`WAIT`命令请求对数据进行同步复制，但是`WAIT`只能确认指定数量的ACK确认复制。
**关于redis复制的说明：**
1、redis使用异步复制（也可以同步复制），副主（replica-to-master）之间会异步确认（ack）处理的数据量。
2、一个主可以有多个副。
3、...
安全和活性失效保障按照我们的思路和设计方案，算法只需具备3个特性就可以实现一个最低保障的分布式锁。安全属性（Safety property）: 独享（相互排斥）。在任意一个时刻，只有一个客户端持有锁。活性A(Liveness property A): 无死锁。即便持有锁的客户端崩溃（crashed)或者网络被分裂（gets partitioned)，锁仍然可以被获取。活性B(Liveness property B): 容错。 只要大部分Redis节点都活着，客户端就可以获取和释放锁.为什么基于故障转移的实现还不够为了更好的理解我们想要改进的方面，我们先分析一下当前大多数基于Redis的分布式锁现状和实现方法.实现Redis分布式锁的最简单的方法就是在Redis中创建一个key，这个key有一个失效时间（TTL)，以保证锁最终会被自动释放掉（这个对应特性2）。当客户端释放资源(解锁）的时候，会删除掉这个key。从表面上看，似乎效果还不错，但是这里有一个问题：这个架构中存在一个严重的单点失败问题。如果Redis挂了怎么办？你可能会说，可以通过增加一个slave节点解决这个问题。但这通常是行...
ElasticSearch分组聚合分页
======
类似SQL里面`group by`后分页输出列表。
这里需要分成两个步骤，一个是计算总数，第二个是输出列表。
### 数据场景：
展示一个车主列表，输入关键字，可以通过车主的姓名、车辆的车牌来搜索出对应的车主数据列表。
添加一个车辆索引：`car`，里面包括车主姓名：`name`，车主id：`uid`，车牌：`car_no`
因为车主和车辆是一对多的关系，所以我们在车辆索引里面搜索车主的时候需要对uid去重，这里就用到了聚合。
### 计算聚合桶的个数
方法就是用`cardinality`聚合和`sum_bucket`聚合结合起来计算。
```json
{
"size": 0,
"query": {
"bool": {
//这里用前缀搜索name和car_no
"should": [
{
"prefix": {
"name": "113566"
}
},
{
"...
我这里说的日志是应用日志，比如Web api 出现的一些异常，错误信息等，收集到一起，方便查询检索。
基本架构是，应用把出现的异常错误信息发送到MQ，再存储到数据库，然后提供一个web前端可以查看和检索。
ELK的主要组件如下：
- elasticsearch：存储数据的地方
- kibana：可视化数据的web前端
- logstash：数据中转的地方，可以收集数据，过滤转换之后存储起来,输入和输出都可配置，默认是elasticsearch，也可以是其他数据库。
- beats：这个是收集特定数据的一组轻量级工具，可以单独安装用来收集特定数据，比如nginx的日志，系统日志，或者是系统监控信息等，这组工具的信息可以直接写入到`elasticsearch`，也可以通过`logstash`写入。和上面三个工具集成度很高，只需要很少的配置就可以完成收集安装。
这里我只是收集应用日志，所以暂时不需要用到`beats`。
数据流向图：
。特别注意，这份配置文件不用修改，可以直接运行在MySQL 5.6和5.7的版本下，这里使用了小小的技巧，具体可看配置文件。如果配置参数存在问题，也可以及时反馈Inside君，我们一起成长。触发Inside君做这件事情的原因是大部分网络上的MySQL配置文件都非常非常古老，大多都是基于MySQL 5.1的版本，这导致了绝大部分MySQL并没有运行在最优的环境，从而导致一些错误的使用，亦或是灾难性事故的发生，比如数据丢失，主从数据不一致等。而这些问题早在5.6版本及以后的版本中得到了解决。最后，抛弃你那所谓的、陈旧的、错误的MySQL配置文件，面向一个崭新的高性能、高可靠、高可扩展MySQL时代，你要做的就是下载这份配置文件...
mysql的utf8并不是完整的utf8，只能存储最多三个字节的字符，而完整的utf8编码是一个字符最多可以占用4个字节的。这就导致一些4个字节的字符不能存进utf8编码的表里面，比如emoji表情符号。mysql5.5.3版本的时候新增了一个新的字符集，叫做utf8mb4，这个就是真正的utf8编码的，也可以直接存储emoji表情符号。utf8mb4的字符范围是包含utf8的，所以，我们可以直接把当前数据库的编码转换成utf8mb4，不会有任何问题。为了避免以后因为字符范围而导致的问题，我们在新建数据库的时候也应该用utf8mb4代替utf8作为默认的字符编码。校验规则的话utf8mb4_general_ci和utf8mb4_unicode_ci都是可以得，mysql默认是前者，前者校验速度较快，后者则更准确一点。那么如何把当前数据库的编码由utf8转换为utf8mb4呢？我们需要下面几步：首先，我们先备份下原来的数据库，是吧？为了保险起见。然后呢！再核对下msyql的版本号，如果版本低于5.5.3的话就先升级一下吧！第三步，修改数据库，表和列，数量少的话可以直接执行sql语句：#修...
1、定位执行效率较低的sql语句通常有两种方法。一种是慢查询日志，用--log-slow-queries[=file_name]启动时，mysql会记录所有执行时间超过long_query_time秒的sql语句的日志文件。 long_query_time参数单位时秒，精度可以精确到微秒，默认情况下管理语句和不使用索引进行查询的语句是不会记录的，如果要记录这两类sql语句可以用--log-slow-admin-statements和log_queries_not_using_indexes来控制。还有一种方法就是使用show processlist命令查看当前mysql在进行的线程，包括线程的状态，是否锁表等，实时的查看sql的执行情况，同时对锁表操作进行优化。2、通过explain分析低效sql的执行计划 explain命令可以获取mysql的执行计划。执行如下命令：EXPLAIN SELECT * FROM `user` WHERE `uid`=1会显示： id: 1
select_type: SIMPLE
table: user
...