weixin_44453179的博客

对于全局变量：引用类型的全局变量分配在堆上值类型的全局变量分配在栈上对于局部变量，要具体情况具体分析，它不取决于是var还是new出来，以下面代码为例：x在函数结束后，仍会被包级别的global使用，也就是局部变量x从函数f中逃逸了，那x必须分配在堆上与之对应的*y在函数g结束后将不再可达，也就是会被立即回收，因此在栈上分配空间var global *intfunc f() { var x int x = 1 global = &x}fun.

redis单线程为什么那么快在内存中操作核心是基于非阻塞的I/O多路复用机制(主进程只会处理命令，不会进行磁盘IO操作)单线程反而避免了多线程频繁上下文切换带来的性能问题redis分布式锁底层是如何实现的过期键的删除策略惰性过期：访问时采取判断是否过期（有点类似于延迟加载，对内存不友好，但是大量节省了cpu资源）定期过期：隔一段时间去扫描一下key（每次扫描一定数量的key，而非全部扫描），这里要注意考虑执行频率和执行Redis的持久化机制机制一RDB(Red

隔离级别可读未提交内容 READ UNCOMMIT可读已提交内容 READ COMMITED（会出现脏读问题）可重复读 （解决了脏读问题，但会导致幻读，不过可以通过MVCC解决掉幻读）可串行化（足够安全，但是效率也足够低）通过强制事务排序，使之不可能产生冲突出现的问题脏读事务A正在更新数据但未提交，此时事务B来读取数据，就会出现读到的数据可能跟最后持久化的数据不一致问题不可重复读- 事务A第一次读取某一行数据返回data1，在第二次读之前有一个事务B对该行数据做了修改

消息队列如何保证消息可靠传输可靠意味着：生产者不重复生产消息（多）、消费者不重复消费消息（多）、消息在传输中不能丢失（少）1、消息重复：对于生产者，一般不会出现多生产的情况。不过为了配合消费者的重复判断逻辑实现，可以在生成消息时，多加一个全局唯一id，这样消费者在每次拿到消息后根据id判断是否消费过对于消费者，不能重复消费，我们可以通过实现幂等性来实现，或者说即使重复消费了，也不会对结果产生影响（我们也需要从代码的层面去实现，比如数据库的唯一索引）2、消息丢失生产者发送消息时，一定要确认

GraplQL是什么？能干啥？一种查询语言，一种API查询语言。GraphQL 这种方式能够将原有 RESTful 风格时的多次请求聚合成一次请求，可以定制查询结果(结构)和REST API的区别：REST1、返回的数据格式和类型都是定义好的，如果想前后端保持预期效果，1）协调后端改接口(工作量/频繁改动)；2）前端自己做适配(会增加网络传输量)。2、某前端展现需要调用多个RESTful API才能获取到足够的数据时，必须要拉取的全部的数据之后，才能绘制界面。GraphQL