盘点2022年最新阿里精选面试题（CC研发岗）

　　一、内存+数据结构
　　1 在 C++ 被 程序中调用被 C C 编译器编译后的函数，为什么要加 extern ＂C＂ 声明？
　　函数和变量被 C++编译后在符号库中的名字与 C 语言的不同，被 extern ＂C＂修饰的变量和函数是按照 C 语言方式编译和连接的。由于编译后的名字不同，C++程序不能直接调用 C 函数。C++提供了一个 C 连接交换指定符号 extern＂C＂来解决这个问题。
　　2. C 中 static 有什么作用?
　　(1)隐藏。
　　当我们同时编译多个文件时，所有未加 static 前缀的全局变量和函数都具有全局可见性，故使用 static 在不同的文件中定义同名函数和同名变量，而不必担心命名冲突。
　　(2)static 的第二个作用是保持变量内容的持久。
　　存储在静态数据区的变量会在程序刚开始运行时就完成初始化，也是唯一的一次初始化。共有两种变量存储在静态存储区：全局变量和 static 变量。
　　(3)static 的第三个作用是默认初始化为 0.
　　其实全局变量也具备这一属性，因为全局变量也存储在静态数据区。在静态数据区，内存中所有的字节默认值都是 0 00,某些时候这一特点可以减少程序员的工作量。
　　3. 内联函数 inline 和宏定义一起使用的区别。
　　内联函数是在编译的时候已经做好将对应的函数代码替换嵌入到对应的位置，适用于代码较少的函数。宏定义是简单的替换变量，如果定义的是有参数的函数形式，参数不做类型校验
　　4 delete []arry 和 和 delete arry 一样吗？不一样请说明；
　　delete []arry 释放的是多个同一类型的地址空间
　　delete arry 释放的是一个某种类型的地址空间
　　5. 内存泄漏
　　未对作废数据内存单元置为 null，尽早释放无用对象的引用，使用临时变量时，让引用变量在推出活动域后自动设置为 null，暗示垃圾收集器收集；
　　程序避免用 String 拼接，用 StringBuffer，因为每个 String 会占用内存一块区域；
　　尽量少用静态变量（全局不会回收）；
　　不要集中创建对象尤其大对象，可以使用流操作；
　　尽量使用对象池，不再循环中创建对象，优化配置；
　　创建对象到单例 getInstance 中，对象无法回收被单例引用；
　　服务器 session 时间设置过长也会引起内存泄漏。
　　6.请描述平衡二叉树.
　　平衡二叉树，左右高度之差不超过 1，Add/delete 可能造成高度>1，此时要旋转，维持
　　平衡状态，避免二叉树退化为链表，让 Add/Delete 时间复杂度但控制在 O(log2N)，旋
　　转算法 2 个方法，1 是求树的高度，2 是求 2 个高度最大值，1 个空树高度为-1，只有 1
　　个根节点的树的高度为 0，以后每一层+1，平衡树任意节点最多有 2 个儿子，因此高度
　　不平衡时，此节点的 2 棵子树高度差为 2。例如单旋转，双旋转，插入等。
　　红黑树放弃完全平衡，追求大致平衡，保证每次插入最多要 3 次旋转就能平衡。
　　7. 请问溢出的原因?
　　是否递归的调用；
　　大量循环；
　　全局变量是否过多；
　　数组，List，Map 数据是否过大；
　　用DDMS 工具检查地方。
　　内存溢出的原因
　　过多使用了 static；static 最好只用 int 和 string 等基本类型；大量的递归或者死循环；大数据项的查询，如返回表的所有记录，应该采用分页查询。检查是否有数组、List、map 中存放的是对象的引用而不是对象，这些引用会让对应对象不能被释放。
　　栈过大会导致内存占用过多，频繁页交换阻碍效率。
　　8. 一个线程池正在处理服务如果忽然断电该怎么办？
　　队列实现持久化储存，下次启动自动载入。
　　但是实际需要看情况，大体思路是这样。
　　添加标志位，未处理 0，处理中 1，已处理 2。每次启动的时候，把所有状态为 1 的，置为 0。或者定时器处理
　　关键性的应用就给电脑配个 UPS。
　　9. 红黑树的特点？
　　（1）每个节点或者是黑色，或者是红色。
　　（2）根节点是黑色。
　　（3）每个叶子节点（NIL）是黑色。注意：这里叶子节点，是指为空(NIL 或 NULL)的叶子节点！
　　（4）如果一个节点是红色的，则它的子节点必须是黑色的。
　　（5）从一个节点到该节点的子孙节点的所有路径上包含相同数目的黑节点。[这里指到叶子节点的路径] 二、网络
　　1 ICMP 是什么协议, , 处于哪一层?
　　Internet 控制报文协议，处于网络层（IP 层）
　　2. 讲一下 NIO 和网络传输.
　　NIO Reactor 反应器模式，例如汽车是乘客访问的实体 reactor，乘客上车后到售票员处 Acceptor 登记，之后乘客 便可休息睡觉了，到达乘客目的地后，售票员 Aceptor 将其唤醒即可。持久 TCP 长链接每个 client 和 server 之间有存在一 个持久连接，当 CCU（用户并发数量）上升，阻塞 server 无法为每个连接运行 1 个线程，自己开发 1 个二进制协议，将 message 压缩至 3-6 倍，传输双向且消息频率高，假设 server 链接了 2000 个 client，每个 client 平均每分钟传输 1-10 个 message，1 个 messaged 的大小为几百字节/几千字节，而 server 也要向 client 广播其他玩家的当前信息，需要高速处 理消息的能力。Buffer，网络字节存放传输的地方，从 channel 中读写，从 buffer 作为中间存储格式，channel 是网络连 接与 buffer 间数据通道，像之前的 socket 的 stream。
　　3. Https 工作流程？
　　a、客户端发送自己支持的加密规则给服务器，代表告诉服务器要进行连接了
　　b、服务器从中选出一套加密算法和 hash 算法以及自己的身份信息(地址等)以证书的形
　　式发送给浏览器，证书中包含服务器信息，加密公钥，证书的办法机构
　　c、客户端收到网站的证书之后要做下面的事情：
　　c1、验证证书的合法性
　　c2、如果验证通过证书，浏览器会生成一串随机数作为密钥 K，并用证书中的公钥进行加密
　　c3、用约定好的 hash 算法计算握手消息，然后用生成的密钥 K 进行加密，然后一起发送给服务器
　　d、服务器接收到客户端传送来的信息，要求下面的事情：
　　d1、用私钥解析出密码，用密码解析握手消息，验证 hash 值是否和浏览器发来的一致
　　d2、使用密钥加密消息，回送
　　如果计算法 hash 值一致，握手成功
　　4. 服务限流的方式？
　　漏桶：水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求。
　　令牌桶算法：系统会按恒定 1/QPS 时间间隔(如果 QPS=100,则间隔是 10ms)往桶里加入Token，如果桶已经满了就不再加了.新请求来临时,会各自拿走一个 Token,如果没有Token 就拒绝服务。
　　基于 redis 实现的限流：假设每分钟访问次数不能超过 10 次，在 Redis 中创建一个键，过期 60 秒，对此服务接口的访问就把键值加 1，在 60 秒内增加到 10 的时候，禁止访问服务接口。
　　计数器，滑动窗口
　　相关视频推荐
　　5种红黑树的场景，从Linux内核谈到Nginx源码，听完醍醐灌顶
　　内存泄漏的3个解决方案与原理实现，知道一个可以轻松应对开发
　　C++后台开发该学哪些内容，标准技术路线（含推荐书籍与项目），面经与算法该如何刷
　　学习地址：C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂三、容器化，分布式
　　1. ZooKeeper 分布式是如何做到高可用?
　　ZooKeeper 运行期间，集群中至少有过半的机器保存了最新数据。集群超过半数的机器能够正常工作，集群就能够对外提供服务。
　　zookeeper 可以选出 N 台机器作主机，它可以实现 M:N 的备份；keepalive 只能选出 1台机器作主机，所以 keepalive 只能实现 M:1 的备份。
　　通常有以下两种部署方案：
　　双机房部署（一个稳定性更好、设备更可靠的机房，这个机房就是主要机房，而另外一个机房则更加廉价一些，例如，对于一个由 7 台机器组成的ZooKeeper 集群，通常在主要机房中部署 4 台机器，剩下的 3 台机器部署到另外一个机房中）；
　　三机房部署（无论哪个机房发生了故障，剩下两个机房的机器数量都超过半数。在三个机房中都部署若干个机器来组成一个 ZooKeeper 集群。假设机器总数为 N，各机房机器数：N1 = (N-1)/2 ，N2=1~(N-N1)/2 ，N3 = N - N1 - N2 ）。
　　水平扩容就是向集群中添加更多机器，Zookeeper2 种方式（不完美），一种是集群整体重启，另外一种是逐台进行服务器的重启。
　　2. kafka 高性能的原因？
　　A，Broker NIO 异步消息处理，实现了 IO 线程与业务线程分离；
　　B，磁盘顺序写；
　　C， 零拷贝（跳过用户缓冲区的拷贝，建立一个磁盘空间和内存的直接映射，数据不再复制到用户态缓冲区）；
　　D，分区/分段（每次文件操作都是对一个小文件的操作，非常轻便，同时也增加了并行处理能力）；
　　F，批量发送 (可以指定缓存的消息达到某个量的时候就发出去，或者缓存了固定的时间后就发送出去，大大减少服务端的 I/O 次数)
　　E，数据压缩
　　3. kafka 消息会不会丢失？
　　Kafka 消息发送分同步(sync)、异步(async)两种方式。默认是使用同步方式，可通过producer.type 属性进行配置；Kafka 保证消息被安全生产，有三个选项分别是 0,1,-1。
　　通过 request.required.acks 属性进行配置：
　　0 代表：不进行消息接收是否成功的确认(默认值)；
　　1 代表：当 Leader 副本接收成功后，返回接收成功确认信息；
　　-1 代表：当 Leader 和 Follower 副本都接收成功后，返回接收成功确认信息；
　　网络异常
　　acks 设置为 0 时，不和 Kafka 集群进行消息接受确认，当网络发生异常等情况时，存在消息丢失的可能；
　　客户端异常
　　异步发送时，消息并没有直接发送至 Kafka 集群，而是在 Client 端按一定规则缓存并批量发送。在这期间，如果客户端发生死机等情况，都会导致消息的丢失；
　　缓冲区满了
　　异步发送时，Client 端缓存的消息超出了缓冲池的大小，也存在消息丢失的可能；
　　Leader 副本异常
　　acks 设置为 1 时，Leader 副本接收成功，Kafka 集群就返回成功确认信息，而 Follower副本可能还在同步。这时 Leader 副本突然出现异常，新 Leader 副本(原 Follower 副本)
　　未能和其保持一致，就会出现消息丢失的情况；
　　以上就是消息丢失的几种情况，在日常应用中，我们需要结合自身的应用场景来选择不同的配置。
　　想要更高的吞吐量就设置：异步、ack=0；想要不丢失消息数据就选：同步、ack=-1 策略
　　4. 怎么理解kafka 的leader 副本选举？
　　如果某个分区 patition 的 Leader 挂了,那么其它跟随者将会进行选举产生一个新的leader,之后所有的读写就会转移到这个新的Leader上,在kafka中,其不是采用常见的多数选举的方式进行副本的Leader选举,而是会在Zookeeper上针对每个Topic维护一个称为 ISR（in-sync replica，已同步的副本）的集合,显然还有一些副本没有来得及同步。只有这个 ISR 列表里面的才有资格成为 leader(先使用 ISR 里面的第一个，如果不行依次类推，因为 ISR 里面的是同步副本，消息是最完整且各个节点都是一样的)。
　　通过 ISR,kafka 需要的冗余度较低，可以容忍的失败数比较高。假设某个 topic 有 f+1个副本，kafka 可以容忍 f 个不可用,当然,如果全部 ISR 里面的副本都不可用,也可以选择其他可用的副本,只是存在数据的不一致。
　　5. 如何理解kafka 消息的检索？
　　其实很简单主要是用二分查找算法,比如我们要查找一条 offest=10000 的文件,kafka首先会在对应分区下的 log 文件里采用二分查看定位到某个记录该 offest=10000 这条消息的 log,然后从相应的 index 文件定位其偏移量,然后拿着偏移量到 log里面直接获取。这样就完成了一个消息的检索过程。
　　6 RabbitMQ 集群方式？
　　1）普通集群：
　　以两个节点（rabbit01、rabbit02）为例来进行说明。
　　rabbit01 和 rabbit02 两个节点仅有相同的元数据，即队列的结构，但消息实体只存在于其中一个节点 rabbit01（或者 rabbit02）中。
　　当消息进入 rabbit01 节点的 Queue 后，consumer 从 rabbit02 节点消费时，RabbitMQ会临时在 rabbit01、rabbit02 间进行消息传输，把 A 中的消息实体取出并经过 B 发送给 consumer。所以 consumer 应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理 Queue。否则无论 consumer 连 rabbit01 或 rabbit02，出口总在 rabbit01，会产生瓶颈。当 rabbit01 节点故障后，rabbit02 节点无法取到rabbit01 节点中还未消费的消息实体。如果做了消息持久化，那么得等 rabbit01 节点恢复，然后才可被消费；如果没有持久化的话，就会产生消息丢失的现象。
　　2）镜像集群：
　　在普通集群的基础上，把需要的队列做成镜像队列，消息实体会主动在镜像节点间同步，而不是在客户端取数据时临时拉取，也就是说多少节点消息就会备份多少份。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用由于镜像队列之间消息自动同步，且内部有选举 master 机制，即使 master 节点宕机也不会影响整个集群的使用，达到去中心化的目的，从而有效的防止消息丢失及服务不可用等问题
　　7 RabbitMQ 消息堆积怎么处理？
　　增加消费者的处理能力(例如优化代码)，或减少发布频率
　　单纯升级硬件不是办法，只能起到一时的作用
　　考虑使用队列最大长度限制，RabbitMQ 3.1 支持给消息设置年龄，超时就丢弃.
　　默认情况下，rabbitmq 消费者为单线程串行消费，设置并发消费两个关键属性concurrentConsumers 和 prefetchCount，concurrentConsumers 设置的是对每个 listener在初始化的时候设置的并发消费者的个数，prefetchCount 是每次一次性从 broker 里面取的待消费的消息的个数
　　建立新的 queue，消费者同时订阅新旧 queue生产者端缓存数据，在 mq 被消费完后再发送到 mq打破发送循环条件，设置合适的 qos 值，当 qos 值被用光，而新的 ack 没有被 mq 接收时，就可以跳出发送循环，去接收新的消息；消费者主动 block 接收进程，消费者感受到接收消息过快时主动 block，利用 block 和 unblock 方法调节接收速率，当接收线程被 block时，跳出发送循环。
　　新建一个 topic，partition 是原来的 10 倍；然后写一个临时的分发数据的 consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue；接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时 queue 的数据；等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的 consumer 机器来消费消息；
　　8. RabbitMQ 的消息丢失解决方案？
　　消息持久化：Exchange 设置持久化：durable:true；Queue 设置持久化；Message 持久化发送。
　　ACK 确认机制：消息发送确认；消息接收确认。
　　9.MQ 如何保证消息的一致性?
　　MQ 做数据同步也会造成不一致，又需要引入监控，实时计算 2 个集群的数据同步，做一致性同步。大部分来说，同步 es 和 solr 不要在代码中去同步，同步失败无法保证事务，而且业务耦合。可以使用 Databug 和 cancel 等工具去做代码解耦，MQ 支持重试，存储失败后抛出异常下次再处理。数据做异构，对外服务时任意拼装，MYSQL 在半同步复制上做了一些优化，保证了一致性，引入了诸如 paxos 等主流算法保证强一致性问题。
　　当 DB（监听从库），binlog 有变化，cancel 监听到时候解析过滤发送 MQ（表名字，主键等）到变化的实时从库中查询数据同步到 ES 聚合表，MQ 可以重试，系统解耦。事务 log挖掘县城会对 DB 的事务 log 监听，并把这些事件发布到消息代理。
　　10. Elasticsearch 分片使用优化?
　　(1)拆分集群
　　对于存在明显分界线的业务，可以按照业务、地域使用不同集群，这种拆分集群的思路是非常靠谱的。对于我们的场景，已经按照地域拆分了集群，且同一地域的子业务间分界线不明显，拆分过多的集群维护成本较高。
　　(2)调整滚动周期
　　根据保留时长调整index滚动周期是最简单有效的思路。例如保留3天的数据按天滚动，保留 31 天的数据按周滚动，保留一年的数据按月滚动。合理的滚动周期，可以在存储成本增加不大的情况下，大幅降低分片数量。
　　对于我们的场景，大部分数据保留 31 天，在按周滚动的情况下，集群的总分片数可以下降到 6.5w~个。
　　(3)合理设置分片数和副本数
　　除个别子业务压力较高外，大部分业务压力较小，合理设置单 Index 的分片数效果也不错。我们的经验是单个分片的大小在 10GB~30GB 之间比较合适，对于压力非常小的业务可以直接分配 1 个分片。其他用户可结合具体场景考虑，同时注意单分片的记录条数不要超过上限 2,147,483,519。
　　在平衡我们的业务场景对数据可靠性的要求 及 不同副本数对存储成本的开销 两个因素之后，我们选择使用一主一从的副本策略。
　　目前我们集群单 Index 的平均分配数为 3，集群的总分片数下降到 3w~个。
　　(4)分片分配流程优化
　　默认情况下，ES 在分配分片时会考虑分片 relocation 对磁盘空间的影响。在分片数较少时，这个优化处理的副作用不明显。但随着单机分片数量的上升，这个优化处理涉及的多层循环嵌套过程耗时愈发明显。可通过cluster.routing.allocation.disk.include_relocations: false 关闭此功能，这对磁盘均衡程度影响不明显。
　　(5)预创建 Index
　　对于单集群 3w 分片的场景，集中在每周某天 0 点创建 Index，对集群的压力还是较大，且存储空间存在波动。考虑到集群的持续扩展能力和可靠性，我们采用预创建方式提前创建分片，并把按 Index 的创建时间均匀打散到每周的每一天。
　　(6)持续调整分片数
　　对于集群分片的调整，通常不是一蹴而就的。随着业务的发展，不断新增的子业务 或 原有子业务规模发生突变，都需要持续调整分片数量。
　　默认情况下，新增的子业务会有默认的分片数量，如果不足，会在测试阶段及上线初期及时发现。随着业务发展，系统会考虑 Index 近期的数据量、写入速度、集群规模等因素，动态调整分片数量。
　　11. 负载均衡算法？
　　常见 6 种负载均衡算法：轮询，随机，源地址哈希，加权轮询，加权随机，最小连接数。
　　nginx5 种负载均衡算法：轮询，weight，ip_hash，fair（响应时间），url_hash
　　dubbo 负载均衡算法：随机，轮询，最少活跃调用数，一致性 Hash 四、数据库
　　1. 使用 mysql 索引都有哪些原则？索引什么数据结构？
　　1、 对于查询频率高的字段创建索引；
　　2、 对排序、分组、联合查询频率高的字段创建索引；
　　3、 索引的数目不宜太多
　　原因： a、每创建一个索引都会占用相应的物理控件；
　　b、过多的索引会导致 insert、update、delete 语句的执行效率降低；
　　4、若在实际中，需要将多个列设置索引时，可以采用多列索引
　　如：某个表(假设表名为 Student)，存在多个字段(StudentNo, StudentName, Sex, Address, Phone,BirthDate)，其中需要对 StudentNo,StudentName 字段进行查询，对Sex 字段进行分组，对 BirthDate 字段进行排序，此时可以创建多列索引 index，index_name (StudentNo, StudentName, Sex, BirthDate);#index_name 为索引名
　　在上面的语句中只创建了一个索引，但是对 4 个字段都赋予了索引的功能。
　　创建多列索引，需要遵循 BTree 类型，即第一列使用时，才启用索引。
　　在上面的创建语句中，只有 mysql 语句在使用到 StudentNo 字段时，索引才会被启用。
　　如: select * from Student where StudentNo = 1000; #使用到了 StudentNo字段，索引被启用。
　　以使用 explain 检测索引是否被启用如:explain select * from Student where StudentNo = 1000;
　　5、选择唯一性索引
　　唯一性索引的值是唯一的，可以更快速的通过该索引来确定某条记录。例如，学生表中学号是具有唯 一性的字段。为该字段建立唯一性索引可以很快的确定某个学生的信息。如果使用姓名的话，可能存 在同名现象，从而降低查询速度。
　　6、尽量使用数据量少的索引
　　如果索引的值很长，那么查询的速度会受到影响。例如，对一个 CHAR(100)类型的字段进行全文检索 需要的时间肯定要比对 CHAR(10)类型的字段需要的时间要多。
　　7、尽量使用前缀来索引
　　如果索引字段的值很长，最好使用值的前缀来索引。例如，TEXT 和 BLOG 类型的字段，进行全文检 索会很浪费时间。如果只检索字段的前面的若干个字符，这样可以提高检索速度。
　　8、删除不再使用或者很少使用的索引.
　　表中的数据被大量更新，或者数据的使用方式被改变后，原有的一些索引可能不再需要。数据库管理 员应当定期找出这些索引，将它们删除，从而减少索引对更新操作的影响 B+ tree 树索引, B tree,散列
　　2. Mysql 有哪些存储引擎？请详细列举其区别？
　　InnoDB: 事务型存储引擎, 并且有较高的并发读取频率
　　MEMORY：存储引擎，存放在内存中，数据量小， 速度快
　　Merge:
　　ARCHIVE：归档， 有很好的压缩机制
　　3. 设计高并发系统数据库层面该如何设计？数据库锁有哪些类型？如何实现？
　　1. 分库分表：同样量的数据平均存储在不同数据库相同表（或不同表）中，减轻单表
　　压力，如果还是很大，就可以每个库在分多张表，根据 hash 取值或者其他逻辑判断将
　　数据存储在哪张表中
　　2. 读写分离：数据库原本就有主从数据库之分，查询在从服务器，增删改在主服务器，
　　3. 归档和操作表区分：建一张归档表，将历史数据放入，需要操作的表数据单独存储
　　4. 索引啊之类的创建，对于数据量很大，百万级别以上的单表，如果增删改操作不频繁的话， 可以创建 bitMap 索引，速度要快得多
　　1. 共享锁：要等第一个人操作完，释放锁，才能操作
　　2. 更新锁：解决死锁，别人可以读，但不能操作
　　3. 排他锁：读写都被禁用
　　4. 意向锁（xlock）：对表中部分数据加锁，查询时，可以跳过
　　5. 计划锁：操作时，别的表连接不了这张表，
　　4. 数据库事务有哪些 ？
　　原子性：所有操作要么全部成功，要么全部失败
　　一致性：例如转账，一个事务执行前和执行后必须一致
　　隔离性：防止脏读， 重复读问题
　　持久性：永久性提交数据库
　　5. Oracle 常用函数有哪些？
　　Concat: 字符串拼接， 或者 ||
　　MConcat: 字符串拼接， 或者 ||
　　Instr: 指定字符串位置
　　Length: 长度
　　Trim: 去空格
　　Lower: 小写
　　Upper:大写
　　Nvl: 判断空
　　Replace: 替换
　　Substr: 截取
　　Floor: 向下取整
　　To_number:
　　To_char:
　　To_date:
　　Decode: 判断函数等等
　　6 Sql 中哪些情况可能不会走索引？
　　1. 查询谓词没有使用索引的主要边界,换句话说就是 select *，可能会导致不走索引
　　2. 单键值的 b 树索引列上存在 null 值，导致 COUNT(*)不能走索引。索引列存在空值
　　3. 索引列上有函数运算，导致不走索引
　　4. 隐式类型转换导致不走索引。
　　5. 表的数据库小或者需要选择大部分数据，不走索引
　　6. ！=或者<>(不等于），可能导致不走索引
　　7. 表字段的属性导致不走索引，字符型的索引列会导致优化器认为需要扫描索引大
　　部分数据且聚簇因子很大，最终导致弃用索引扫描而改用全表扫描方式，
　　8. 使用 like, in 等， 可能导致不走索引
　　7. 讲讲分布式唯一 ID ？
　　确定 ID 存储用 64 位，1 个 64 位二进制 1 是这样的 00000000.....1100......0101，切割 64 位，某段二进制表示成 1 个约束条件，前 41 位为毫秒时间，后紧接 9 位为 IP，IP 之后为自增的二进制，记录当前面位数相同情况下是第几个 id，如现在有 10 台机器，这个 id 生成器生成 id 极限是同台机器 1ms 内生成 2 的 14 次方个 ID。
　　分布式唯一 ID = 时间戳 << 41 位， int 类型服务器编号 << 10，序列自增 sequence。
　　每个时间戳内只能生成固定数量如（10 万）个自增号，达到最大值则同步等待下个时间戳，自增从 0 开始。将毫秒数放在最高位，保证生成的 ID 是趋势递增的，每个业务线、每个机房、每个机器生成的 ID 都是不同的。如 39bit 毫秒数|4bit 业务线|2bit机房|预留|7bit 序列号。高位取 2016 年 1 月 1 日 1 到现在的毫秒数，系统运行 10 年，至少需要 10 年 x365 天 x24 小时 x3600 秒 x1000 毫秒=320x10~9，差不多 39bit 给毫秒数，每秒单机高峰并发小于 100，差不多 7bit 给每毫秒的自增号，5 年内机房小于 100台机器，预留 2bit 给机房，每个机房小于 100 台机器，预留 7bit 给每个机房，业务线
　　小于 10 个，预留 4bit 给业务线标识。
　　64bit 分布式 ID（42bit 毫秒+5bit 机器 ID+12 位自增）等
　　生成分布式 ID 的方式：A，2 个自增表，步长相互隔开 B，时间的毫秒或者纳秒 C，UUID，64 位约束条件（如上）
　　8 Redis 内存数据上升到一定大小会执行数据淘汰策略，Redis 提供了哪 6 种数据淘汰策略?
　　LRU：从已设置过期时间的数据集合中挑选最近最少使用的数据淘汰
　　random：从已设置过期时间的数据中挑选任意数据淘汰
　　ttl：从已设置过期时间的数据集合中挑选将要过期的数据淘汰。
　　notenvision：禁止驱逐数据
　　如 mysql 中有 2 千万数据，redis 只存储 20 万的热门数据。LRU 或者 TTL 都满足热点数
　　据读取较多，不太可能超时特点。
　　redis 特点：速度块，O(1)，丰富的数据类型，支持事物原子性，可用于缓存，比 memecache
　　速度块，可以持久化数据。
　　常见问题和解决：Master 最好不做持久化如 RDB 快照和 AOF 日志文件；如果数据比较重要，某分 slave 开启 AOF 备份数据，策略为每秒 1 次，为了主从复制速度及稳定，MS主从在同一局域网内；主从复制不要用图状结构，用单向链表更为稳定 M-S-S-S-S
　　redis 过期采用懒汉+定期，懒汉即 get/set 时候检查 key 是否过期，过期则删除 key，定期遍历每个 DB，检查制定个数个 key；结合服务器性能调节并发情况。
　　过期淘汰，数据写入 redis 会附带 1 个有效时间，这个有效时间内该数据被认为是正确的并不关心真实情况，例如对支付等业务采用版本号实现，redis 中每一份数据都维持1 个版本号，DB 中也维持 1 份，只有当 redis 的与 DB 中的版本一致时，才会认为 redis为有效的，不过仍然每次都要访问 DB，只需要查询 version 版本字段即可。
　　9. 请描述 MyISM 和 和 InnoDB?
　　MyISM 采用表级锁，对 Myism 表读不会阻塞读，会阻塞同表写，对 Myism 写则会阻塞读和写，即一个线程获得 1 个表的写锁后，只有持有锁的线程可以对表更新操作，其他线程的读和写都会等待。
　　InnoDB，采用行级锁，支持事务，例如只对 a 列加索引，如果 update ...where a=1 and b=2 其实也会锁整个表， select 使用共享锁，update insert delete 采用排它锁，commit 会把锁取消，当然 select by id for update 也可以制定排它锁。
　　10. 请描述实时队列?
　　实时队列采用双队列模式，生产者将行为记录写入 Queue1，worker 服务从 Queue1 消费新鲜数据，如果异常则写入 Queue2（主要保存异常数据），RetryWorker 会监听 Queue2，消费异常数据，如果还未处理成功按照一定的策略等待或者将异常数据再写入 Queue2，如果数据发生积压可以调整 worker 的消费游标，从最新数据重新开始消费，保证了最新 data 得到处理，中间未处理的一段则可以启动 backupWorker 指定起止游标在消费完
　　指定区间的数据后，backupWorker 会自动停止。
　　DB 降级开关后，可直接写入 redis（storm），同时将数据写入一份到 Retry 队列，在开启 DB 降级开关后消费 Retry 队列中的数据，从而把数据写入到 mysql 中，达到最终一致性。MYSQL 切分为分片为 2 的 N 次方，例如原来分为两个库 d0 和 d1 均放在 s0 服务器上，s0 同时有备机 s1，扩容只要几步骤：确保 s0 到 s1 服务器同步顺利，没有明显延迟；s0 暂时关闭读写权限；确保 s1 已经完全同步到 s0 更新；s1 开放读写权限；
　　d1 的 dns 由 s0 切换到 s1；s0 开放读写权限。
　　11.DB 的特性和隔离级别？
　　4 大特性：原子性，一致性，分离性，持久性
　　隔离级别：
　　读提交：写事务禁止读
　　读未提交：写事务允许读
　　可重复读：写事务禁止读事务，读禁止写
　　序列化：全部禁止
　　详细说明：读提交 1 个事务开始写则全部禁止其他事务访问该行。读未提交 1 个事务开
　　始写则不允许其他事务同时写，但可以读。可重复读 读事务会禁止写事务，写事物则
　　禁止其他任何事务。序列化性能最低，全部禁止，串行执行。MYSQL 默认的是可重复
　　读。
　　12. mysql 数据库锁表怎么解决？
　　查询锁表信息
　　当前运行的所有事务
　　select * from information_schema.innodb_trx
　　当前出现的锁
　　select * from information_schema.innodb_locks
　　锁等待的对应关系
　　select * from information_schema.innodb_lock_waits
　　通过 select * from information_schema.innodb_trx 查询 trx_mysql_thread_id 然
　　后执行 kill 线程 ID
　　KILL 8807;//后面的数字即时进程的 ID