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

　　一、内存数据结构
　　1在C被程序中调用被CC编译器编译后的函数，为什么要加externC声明？
　　函数和变量被C编译后在符号库中的名字与C语言的不同，被externC修饰的变量和函数是按照C语言方式编译和连接的。由于编译后的名字不同，C程序不能直接调用C函数。C提供了一个C连接交换指定符号externC来解决这个问题。
　　2。C中static有什么作用？
　　（1）隐藏。
　　当我们同时编译多个文件时，所有未加static前缀的全局变量和函数都具有全局可见性，故使用static在不同的文件中定义同名函数和同名变量，而不必担心命名冲突。
　　（2）static的第二个作用是保持变量内容的持久。
　　存储在静态数据区的变量会在程序刚开始运行时就完成初始化，也是唯一的一次初始化。共有两种变量存储在静态存储区：全局变量和static变量。
　　（3）static的第三个作用是默认初始化为0。
　　其实全局变量也具备这一属性，因为全局变量也存储在静态数据区。在静态数据区，内存中所有的字节默认值都是000，某些时候这一特点可以减少程序员的工作量。
　　3。内联函数inline和宏定义一起使用的区别。
　　内联函数是在编译的时候已经做好将对应的函数代码替换嵌入到对应的位置，适用于代码较少的函数。宏定义是简单的替换变量，如果定义的是有参数的函数形式，参数不做类型校验
　　4delete〔〕arry和和deletearry一样吗？不一样请说明；
　　delete〔〕arry释放的是多个同一类型的地址空间
　　deletearry释放的是一个某种类型的地址空间
　　5。内存泄漏
　　未对作废数据内存单元置为null，尽早释放无用对象的引用，使用临时变量时，让引用变量在推出活动域后自动设置为null，暗示垃圾收集器收集；
　　程序避免用String拼接，用StringBuffer，因为每个String会占用内存一块区域；
　　尽量少用静态变量（全局不会回收）；
　　不要集中创建对象尤其大对象，可以使用流操作；
　　尽量使用对象池，不再循环中创建对象，优化配置；
　　创建对象到单例getInstance中，对象无法回收被单例引用；
　　服务器session时间设置过长也会引起内存泄漏。
　　6。请描述平衡二叉树。
　　平衡二叉树，左右高度之差不超过1，Adddelete可能造成高度1，此时要旋转，维持
　　平衡状态，避免二叉树退化为链表，让AddDelete时间复杂度但控制在O（log2N），旋
　　转算法2个方法，1是求树的高度，2是求2个高度最大值，1个空树高度为1，只有1
　　个根节点的树的高度为0，以后每一层1，平衡树任意节点最多有2个儿子，因此高度
　　不平衡时，此节点的2棵子树高度差为2。例如单旋转，双旋转，插入等。
　　红黑树放弃完全平衡，追求大致平衡，保证每次插入最多要3次旋转就能平衡。
　　7。请问溢出的原因？
　　是否递归的调用；
　　大量循环；
　　全局变量是否过多；
　　数组，List，Map数据是否过大；
　　用DDMS工具检查地方。
　　内存溢出的原因
　　过多使用了static最好只用int和string等基本类型；大量的递归或者死循环；大数据项的查询，如返回表的所有记录，应该采用分页查询。检查是否有数组、List、map中存放的是对象的引用而不是对象，这些引用会让对应对象不能被释放。
　　栈过大会导致内存占用过多，频繁页交换阻碍效率。
　　8。一个线程池正在处理服务如果忽然断电该怎么办？
　　队列实现持久化储存，下次启动自动载入。
　　但是实际需要看情况，大体思路是这样。
　　添加标志位，未处理0，处理中1，已处理2。每次启动的时候，把所有状态为1的，置为0。或者定时器处理
　　关键性的应用就给电脑配个UPS。
　　9。红黑树的特点？
　　（1）每个节点或者是黑色，或者是红色。
　　（2）根节点是黑色。
　　（3）每个叶子节点（NIL）是黑色。注意：这里叶子节点，是指为空（NIL或NULL）的叶子节点！
　　（4）如果一个节点是红色的，则它的子节点必须是黑色的。
　　（5）从一个节点到该节点的子孙节点的所有路径上包含相同数目的黑节点。〔这里指到叶子节点的路径〕二、网络
　　1ICMP是什么协议，，处于哪一层？
　　Internet控制报文协议，处于网络层（IP层）
　　2。讲一下NIO和网络传输。
　　NIOReactor反应器模式，例如汽车是乘客访问的实体reactor，乘客上车后到售票员处Acceptor登记，之后乘客便可休息睡觉了，到达乘客目的地后，售票员Aceptor将其唤醒即可。持久TCP长链接每个client和server之间有存在一个持久连接，当CCU（用户并发数量）上升，阻塞server无法为每个连接运行1个线程，自己开发1个二进制协议，将message压缩至36倍，传输双向且消息频率高，假设server链接了2000个client，每个client平均每分钟传输110个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。服务限流的方式？
　　漏桶：水（请求）先进入到漏桶里，漏桶以一定的速度出水（接口有响应速率），当水流入速度过大会直接溢出（访问频率超过接口响应速率），然后就拒绝请求。
　　令牌桶算法：系统会按恒定1QPS时间间隔（如果QPS100，则间隔是10ms）往桶里加入Token，如果桶已经满了就不再加了。新请求来临时，会各自拿走一个Token，如果没有Token就拒绝服务。
　　基于redis实现的限流：假设每分钟访问次数不能超过10次，在Redis中创建一个键，过期60秒，对此服务接口的访问就把键值加1，在60秒内增加到10的时候，禁止访问服务接口。
　　计数器，滑动窗口
　　相关视频推荐
　　5种红黑树的场景，从Linux内核谈到Nginx源码，听完醍醐灌顶
　　内存泄漏的3个解决方案与原理实现，知道一个可以轻松应对开发
　　C后台开发该学哪些内容，标准技术路线（含推荐书籍与项目），面经与算法该如何刷
　　学习地址：CCLinux服务器开发后台架构师【零声教育】学习视频教程腾讯课堂三、容器化，分布式
　　1。ZooKeeper分布式是如何做到高可用？
　　ZooKeeper运行期间，集群中至少有过半的机器保存了最新数据。集群超过半数的机器能够正常工作，集群就能够对外提供服务。
　　zookeeper可以选出N台机器作主机，它可以实现M：N的备份；keepalive只能选出1台机器作主机，所以keepalive只能实现M：1的备份。
　　通常有以下两种部署方案：
　　双机房部署（一个稳定性更好、设备更可靠的机房，这个机房就是主要机房，而另外一个机房则更加廉价一些，例如，对于一个由7台机器组成的ZooKeeper集群，通常在主要机房中部署4台机器，剩下的3台机器部署到另外一个机房中）；
　　三机房部署（无论哪个机房发生了故障，剩下两个机房的机器数量都超过半数。在三个机房中都部署若干个机器来组成一个ZooKeeper集群。假设机器总数为N，各机房机器数：N1（N1）2，N21（NN1）2，N3NN1N2）。
　　水平扩容就是向集群中添加更多机器，Zookeeper2种方式（不完美），一种是集群整体重启，另外一种是逐台进行服务器的重启。
　　2。kafka高性能的原因？
　　A，BrokerNIO异步消息处理，实现了IO线程与业务线程分离；
　　B，磁盘顺序写；
　　C，零拷贝（跳过用户缓冲区的拷贝，建立一个磁盘空间和内存的直接映射，数据不再复制到用户态缓冲区）；
　　D，分区分段（每次文件操作都是对一个小文件的操作，非常轻便，同时也增加了并行处理能力）；
　　F，批量发送（可以指定缓存的消息达到某个量的时候就发出去，或者缓存了固定的时间后就发送出去，大大减少服务端的IO次数）
　　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副本）
　　未能和其保持一致，就会出现消息丢失的情况；
　　以上就是消息丢失的几种情况，在日常应用中，我们需要结合自身的应用场景来选择不同的配置。
　　想要更高的吞吐量就设置：异步、ack0；想要不丢失消息数据就选：同步、ack1策略
　　4。怎么理解kafka的leader副本选举？
　　如果某个分区patition的Leader挂了，那么其它跟随者将会进行选举产生一个新的leader，之后所有的读写就会转移到这个新的Leader上，在kafka中，其不是采用常见的多数选举的方式进行副本的Leader选举，而是会在Zookeeper上针对每个Topic维护一个称为ISR（insyncreplica，已同步的副本）的集合，显然还有一些副本没有来得及同步。只有这个ISR列表里面的才有资格成为leader（先使用ISR里面的第一个，如果不行依次类推，因为ISR里面的是同步副本，消息是最完整且各个节点都是一样的）。
　　通过ISR，kafka需要的冗余度较低，可以容忍的失败数比较高。假设某个topic有f1个副本，kafka可以容忍f个不可用，当然，如果全部ISR里面的副本都不可用，也可以选择其他可用的副本，只是存在数据的不一致。
　　5。如何理解kafka消息的检索？
　　其实很简单主要是用二分查找算法，比如我们要查找一条offest10000的文件，kafka首先会在对应分区下的log文件里采用二分查看定位到某个记录该offest10000这条消息的log，然后从相应的index文件定位其偏移量，然后拿着偏移量到log里面直接获取。这样就完成了一个消息的检索过程。
　　6RabbitMQ集群方式？
　　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节点宕机也不会影响整个集群的使用，达到去中心化的目的，从而有效的防止消息丢失及服务不可用等问题
　　7RabbitMQ消息堆积怎么处理？
　　增加消费者的处理能力（例如优化代码），或减少发布频率
　　单纯升级硬件不是办法，只能起到一时的作用
　　考虑使用队列最大长度限制，RabbitMQ3。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倍数量的接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据；等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息；
　　8。RabbitMQ的消息丢失解决方案？
　　消息持久化：Exchange设置持久化：durable：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的分片数效果也不错。我们的经验是单个分片的大小在10GB30GB之间比较合适，对于压力非常小的业务可以直接分配1个分片。其他用户可结合具体场景考虑，同时注意单分片的记录条数不要超过上限2，147，483，519。
　　在平衡我们的业务场景对数据可靠性的要求及不同副本数对存储成本的开销两个因素之后，我们选择使用一主一从的副本策略。
　　目前我们集群单Index的平均分配数为3，集群的总分片数下降到3w个。
　　（4）分片分配流程优化
　　默认情况下，ES在分配分片时会考虑分片relocation对磁盘空间的影响。在分片数较少时，这个优化处理的副作用不明显。但随着单机分片数量的上升，这个优化处理涉及的多层循环嵌套过程耗时愈发明显。可通过cluster。routing。allocation。disk。includerelocations：false关闭此功能，这对磁盘均衡程度影响不明显。
　　（5）预创建Index
　　对于单集群3w分片的场景，集中在每周某天0点创建Index，对集群的压力还是较大，且存储空间存在波动。考虑到集群的持续扩展能力和可靠性，我们采用预创建方式提前创建分片，并把按Index的创建时间均匀打散到每周的每一天。
　　（6）持续调整分片数
　　对于集群分片的调整，通常不是一蹴而就的。随着业务的发展，不断新增的子业务或原有子业务规模发生突变，都需要持续调整分片数量。
　　默认情况下，新增的子业务会有默认的分片数量，如果不足，会在测试阶段及上线初期及时发现。随着业务发展，系统会考虑Index近期的数据量、写入速度、集群规模等因素，动态调整分片数量。
　　11。负载均衡算法？
　　常见6种负载均衡算法：轮询，随机，源地址哈希，加权轮询，加权随机，最小连接数。
　　nginx5种负载均衡算法：轮询，weight，iphash，fair（响应时间），urlhash
　　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，indexname（StudentNo，StudentName，Sex，BirthDate）；indexname为索引名
　　在上面的语句中只创建了一个索引，但是对4个字段都赋予了索引的功能。
　　创建多列索引，需要遵循BTree类型，即第一列使用时，才启用索引。
　　在上面的创建语句中，只有mysql语句在使用到StudentNo字段时，索引才会被启用。
　　如：selectfromStudentwhereStudentNo1000；使用到了StudentNo字段，索引被启用。
　　以使用explain检测索引是否被启用如：explainselectfromStudentwhereStudentNo1000；
　　5、选择唯一性索引
　　唯一性索引的值是唯一的，可以更快速的通过该索引来确定某条记录。例如，学生表中学号是具有唯一性的字段。为该字段建立唯一性索引可以很快的确定某个学生的信息。如果使用姓名的话，可能存在同名现象，从而降低查询速度。
　　6、尽量使用数据量少的索引
　　如果索引的值很长，那么查询的速度会受到影响。例如，对一个CHAR（100）类型的字段进行全文检索需要的时间肯定要比对CHAR（10）类型的字段需要的时间要多。
　　7、尽量使用前缀来索引
　　如果索引字段的值很长，最好使用值的前缀来索引。例如，TEXT和BLOG类型的字段，进行全文检索会很浪费时间。如果只检索字段的前面的若干个字符，这样可以提高检索速度。
　　8、删除不再使用或者很少使用的索引。
　　表中的数据被大量更新，或者数据的使用方式被改变后，原有的一些索引可能不再需要。数据库管理员应当定期找出这些索引，将它们删除，从而减少索引对更新操作的影响Btree树索引，Btree，散列
　　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：向下取整
　　Tonumber：
　　Tochar：
　　Todate：
　　Decode：判断函数等等
　　6Sql中哪些情况可能不会走索引？
　　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毫秒320x109，差不多39bit给毫秒数，每秒单机高峰并发小于100，差不多7bit给每毫秒的自增号，5年内机房小于100台机器，预留2bit给机房，每个机房小于100台机器，预留7bit给每个机房，业务线
　　小于10个，预留4bit给业务线标识。
　　64bit分布式ID（42bit毫秒5bit机器ID12位自增）等
　　生成分布式ID的方式：A，2个自增表，步长相互隔开B，时间的毫秒或者纳秒C，UUID，64位约束条件（如上）
　　8Redis内存数据上升到一定大小会执行数据淘汰策略，Redis提供了哪6种数据淘汰策略？
　　LRU：从已设置过期时间的数据集合中挑选最近最少使用的数据淘汰
　　random：从已设置过期时间的数据中挑选任意数据淘汰
　　ttl：从已设置过期时间的数据集合中挑选将要过期的数据淘汰。
　　notenvision：禁止驱逐数据
　　如mysql中有2千万数据，redis只存储20万的热门数据。LRU或者TTL都满足热点数
　　据读取较多，不太可能超时特点。
　　redis特点：速度块，O（1），丰富的数据类型，支持事物原子性，可用于缓存，比memecache
　　速度块，可以持久化数据。
　　常见问题和解决：Master最好不做持久化如RDB快照和AOF日志文件；如果数据比较重要，某分slave开启AOF备份数据，策略为每秒1次，为了主从复制速度及稳定，MS主从在同一局域网内；主从复制不要用图状结构，用单向链表更为稳定MSSSS
　　redis过期采用懒汉定期，懒汉即getset时候检查key是否过期，过期则删除key，定期遍历每个DB，检查制定个数个结合服务器性能调节并发情况。
　　过期淘汰，数据写入redis会附带1个有效时间，这个有效时间内该数据被认为是正确的并不关心真实情况，例如对支付等业务采用版本号实现，redis中每一份数据都维持1个版本号，DB中也维持1份，只有当redis的与DB中的版本一致时，才会认为redis为有效的，不过仍然每次都要访问DB，只需要查询version版本字段即可。
　　9。请描述MyISM和和InnoDB？
　　MyISM采用表级锁，对Myism表读不会阻塞读，会阻塞同表写，对Myism写则会阻塞读和写，即一个线程获得1个表的写锁后，只有持有锁的线程可以对表更新操作，其他线程的读和写都会等待。
　　InnoDB，采用行级锁，支持事务，例如只对a列加索引，如果update。。。wherea1andb2其实也会锁整个表，select使用共享锁，updateinsertdelete采用排它锁，commit会把锁取消，当然selectbyidforupdate也可以制定排它锁。
　　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数据库锁表怎么解决？
　　查询锁表信息
　　当前运行的所有事务
　　selectfrominformationschema。innodbtrx
　　当前出现的锁
　　selectfrominformationschema。innodblocks
　　锁等待的对应关系
　　selectfrominformationschema。innodblockwaits
　　通过selectfrominformationschema。innodbtrx查询trxmysqlthreadid然
　　后执行kill线程ID
　　KILL8807；后面的数字即时进程的ID