Golang 开发高频面试题

什么时候才应该把参数定义成类型T,什么情况下定义成类型*T呢。

一般的判断标准是看副本创建的成本和需求。

1. 不想变量被修改。 如果你不想变量被函数和方法所修改，那么选择类型T。相反，如果想修改原始的变量，则选择*T
2. 如果变量是一个大的struct或者数组，则副本的创建相对会影响性能，这个时候考虑使用*T，只创建新的指针，这个区别是巨大的
3. (不针对函数参数，只针对本地变量／本地变量)对于函数作用域内的参数，如果定义成T,Go编译器尽量将对象分配到栈上，而*T很可能会分配到对象上，这对垃圾回收会有影响

简单地比较Redis与Memcached的区别:
1、 Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储。memcache数据结构单一，redis丰富一些，数据操作方面，redis更好一些，较少的网络IO次数
2、 Redis支持数据的备份，即master-slave模式的数据备份。
3、 Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。

4、存储数据安全--memcache挂掉后，数据没了；redis可以定期保存到磁盘（持久化）；

5、灾难恢复--memcache挂掉后，数据不可恢复; redis数据丢失后可以通过aof恢复；

memcache能接受的key的最大长度是250个字符。对iterm 的过期时间最大可达30天；最大能存储的单个iterm是1MB，大于1MB可以考虑在客户端压缩或拆分到多个key中。

缓存击穿和缓存穿透区别，如何解决？

缓存穿透

 缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。

      解决方案：

1. 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
2. 从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击

缓存击穿

      缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力

      解决方案：

1. 设置热点数据永远不过期。
2. 加互斥锁，

缓存雪崩

      缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，        缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

     解决方案：

1. 缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
2. 如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
3. 设置热点数据永远不过期。

一、raft算法

一个 etcd 集群，通常会由 3 个或者 5 个节点组成，多个节点之间通过 Raft 一致性算法的完成分布式一致性协同，算法会选举出一个主节点作为 leader，由 leader 负责数据的同步与数据的分发。当 leader 出现故障后系统会自动地选取另一个节点成为 leader，并重新完成数据的同步。客户端在多个节点中，仅需要选择其中的任意一个就可以完成数据的读写，内部的状态及数据协同由 etcd 自身完成。

• 简单：基于HTTP+JSON的API让你用url命令就可以轻松使用。
• 安全：可选SSL客户认证机制。
• 快速：每个实例每秒支持一千次写操作。
• 可信：使用Raft算法充分实现了分布式。

leader选举的过程是：1、增加term号；2、给自己投票；3、重置选举超时计时器；4、发送请求投票的RPC给其它节点。

Raft是一个用于管理日志一致性的协议。它将分布式一致性分解为多个子问题：Leader选举（Leader election）、日志复制（Log replication）、安全性（Safety）、日志压缩（Log compaction）等。同时，Raft算法使用了更强的假设来减少了需要考虑的状态，使之变的易于理解和实现。Raft将系统中的角色分为领导者（Leader）、跟从者（Follower）和候选者（Candidate）：

• Leader：接受客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后告诉Follower提交日志。

• Follower：接受并持久化Leader同步的日志，在Leader告之日志可以提交之后，提交日志。

• Candidate：Leader选举过程中的临时角色。

1、Raft分为哪几个部分？

  主要是分为leader选举、日志复制、日志压缩、成员变更等。

2、Raft中任何节点都可以发起选举吗？

  Raft发起选举的情况有如下几种：

• 刚启动时，所有节点都是follower，这个时候发起选举，选出一个leader；

• 当leader挂掉后，时钟最先跑完的follower发起重新选举操作，选出一个新的leader。

• 成员变更的时候会发起选举操作。

3、Raft中选举中给候选人投票的前提？

  Raft确保新当选的Leader包含所有已提交（集群中大多数成员中已提交）的日志条目。这个保证是在RequestVoteRPC阶段做的，candidate在发送RequestVoteRPC时，会带上自己的last log entry的term_id和index，follower在接收到RequestVoteRPC消息时，如果发现自己的日志比RPC中的更新，就拒绝投票。日志比较的原则是，如果本地的最后一条log entry的term id更大，则更新，如果term id一样大，则日志更多的更大(index更大)。

5、Raft数据一致性如何实现？

  主要是通过日志复制实现数据一致性，leader将请求指令作为一条新的日志条目添加到日志中，然后发起RPC 给所有的follower，进行日志复制，进而同步数据。