simulation02

深维：
一面：

1.用过哪些分布式锁 redis key用什么类型 用string有什么坏处 ？没抢到的都在干等着，浪费cpu？如何规避。 etcd如何分布式锁

redis 锁 可能存在的问题：

• 业务超时，导致锁失效，造成多实例持有锁：延长过期时间（不推荐）；类似 java 的看门狗机制，另外启用一个协程对锁续约。
• redis 主从切换时可能造成多实例持有锁，这个是用的 redlock 来解决的，不过具体的方案我就没有看过了
  用过redis锁， setnx属于原子操作，上锁失败一般认为是锁已经存在了。一般使用string类型作为key，string类型有一个缺点是会占用比较大的空间，
  可以根据业务具体情况使用 hset ，但是需要保证单个集合中的 kv 数量，如果超过某个界限，redis 就不会用 ziplist 来存储这个集合了

2.数据库 隔离级别 没有解决什么问题 幻读是什么

一共有五种：
不使用事务
read uncommitted 允许脏读
read committed 防止脏读 最常用
repeatable read 防止脏读，不可重复读 mysql 默认
serilized 串行事务，防止幻读，脏读，不可重复读
级别越高，安全性越好，并发性能约低

幻读就是在一个事务过程中用相同条件查询时，获取的结果不一致
事务A获取的结果集，事务B对其中的数据进行了修改并提交，事务A在重新执行查询时，可能会发现原本不存在的数据行（幻影），或者原本存在的数据行消失了

5.slice和数组的区别 各自的好处 地址引用和值引用的好处

区别仅在于数据在声明时定长，切片可拓展长度
值引用是对原数据进行了一份拷贝后传入函数，一般用于函数改值不影响原数据的场景；地址引用是对原数据地址指针的引用，一般函数中对于这个引用的改动会反映到原数据上

6.mysql的索引如何实现的，二级索引如何实现的

由于聚集索引是利用表的主键构建的，所以每张表只能拥有一个聚集索引。

聚集索引的叶子节点就是数据页。换句话说，数据页上存放的是完整的每行记录。因此聚集索引的一个优点就是：通过过聚集索引能获取完整的整行数据。另一个优点是：对于主键的排序查找和范围查找速度非常快。
使用B+树作为索引结构，其中聚集索引（Primary Index）的叶子节点包含行数据，而非聚集索引（Secondary Index）的叶子节点包含主键值。
二级索引（也称为辅助索引）实现方式与主索引类似，只是它不是主键。在InnoDB中，二级索引的叶子节点包含指向主键的指针，这个指针用于回表查询获取完整的数据行。

7.map的底层如何实现的 什么类型不能用做map的key

9.如何实现LRU

双向链表 + 哈希表
双向链表存储节点，哈希表存储节点值到节点地址的映射

10.索引（a,b,c) a= b= c=, c= b= a=, a= b> c=命中索引的哪一段

11.数据库间隙锁是什么

MySQL InnoDB支持三种行锁定方式：

行锁（Record Lock）：锁直接加在索引记录上面。
间隙锁（Gap Lock）：锁加在不存在的空闲空间，可以是两个索引记录之间，也可能是第一个索引记录之前或最后一个索引之后的空间。
Next-Key Lock：行锁与间隙锁组合起来用就叫做Next-Key Lock。

在一般范围区间查询数据时，会对命中的行加行锁，但是对于条件范围内但是还不存在的行也会加间隙锁。如果上一次区间查询没有执行完毕，那么针对该表区间内的insert操作会因为间隙锁而阻塞，直到查询执行完毕才会继续执行
可以解决幻读问题

可以防止数据误删改

时间	事务A	事务B
T0	BEGIN;	BEGIN;
T1	delete from t_student where id < 4;
T2		insert into t_student VALUES(2,‘戏子111’,1,“杭州”);
T3		commit;
T4	commit;
会对插入性能有一定影响

12.分布式事务了解过哪些 如何实现

13.电商系统如何防止超买超卖

一般来说，超买超卖发生在高并发的情况下。那么针对高并发的情况，可以通过加并发锁控制并发；采用队列方式改为顺序执行；利用数据库的原子语句（不推荐）
一般减库存区分 下单、付款、预扣（例如下单后保留10分钟）这几个节点

14.悲观锁和乐观锁分别适合什么样的场景

悲观锁：担心数据被他人修改，因此每次修改都期望加锁，适合写大于读的情况。主要利用数据库中的读锁，行锁，写锁
乐观锁因为不担心数据修改问题，更多适合读大于写的场景，使用版本号或者时间戳（updatetime）

15.负载均衡 etcd如何做 NGINX如何做 k8s如何做

轮询和加权轮询；权重可以根据节点的状态来动态调整。要注意权重的上下限
一致性哈希： 哈希环，服务端节点在环上，距离哈希结果最近的下一个节点
最少连接数
最快响应等

16.普罗米修斯

17.traceid系统怎么做的 如何从前端传到后端各个服务

伴鱼使用的是jager，最初的采集方式是每隔一段时间采集一次。主要用来排查异常，解决业务问题，但是有间隔的采样命中相关异常的概率很小，经常是遇到了问题但是采集不到。后期结合社区内的一些组件，更新了采集方式，

二面：
1.挑一个项目能代表你的架构设计或者解决问题的能力（需要偏技术而不是业务）

2.如何做服务治理

3.etcd是ap系统还是cp系统
==etcd是CP实现==,它保证一致性与分区容错性,一定程度上牺牲了可用性。

4.etcd如何做负载均衡

5.K8S+docker A服务调用B服务是怎么知道B服务的地址的

6.降级限流熔断怎么做的 熔断的原理是什么

1. 降级（Degradation）
   概念：降级是指在系统遇到异常或高负载等情况下，暂时关闭或者切换到一些功能简化的模式，以保证核心流程的可用性和稳定性。
   作用：通过舍弃一些非核心或不重要的功能，保护核心功能的正常运行。
   示例：在高负载情况下，关闭一些消耗较大的查询功能，只提供基本的读写操作。
2. 熔断（Circuit Breaker）
   概念：熔断是指在服务调用过程中，当某个服务出现故障或不可用时，暂时停止调用该服务，直到服务恢复正常。
   作用：通过熔断机制，保护系统免受故障服务的影响，避免雪崩效应。
   示例：监控服务调用的失败率或错误率，当达到一定阈值时，打开熔断器，停止对该服务的调用。一段时间后，再进行尝试，如果调用成功，则关闭熔断器，继续正常调用。
3. 限流（Rate Limiting）
   概念：限流是指在系统的请求流量过大时，对请求进行控制和限制，使得系统在可接受的范围内进行处理，避免系统超出处理能力而崩溃。
   作用：通过限制请求的数量或速度，保护系统免受过载的影响。
   示例：设置每秒最大请求数或最大并发数，当请求数或并发数达到阈值时，拒绝额外的请求或者将其放入等待队列，直到系统能够处理。

7.post报文由什么组成

8.tcp如何定位双方 三次握手

9.如果有M个东西，每8个为一组，每两组之间有两个重叠，会分成多少组

10.人才管理

11.逃逸分析

12.设计模式

grpc 和 http 的区别

grpc的话是使用 http/2 协议进行通信，传输内容为二进制内容，因此grpc的关键算法是 payload 的序列化和反序列化，一般使用 protocol buffer 序列化库。服务之间使用 rpc 调用

数据序列化：

gRPC使用Protocol Buffers对数据进行序列化和反序列化，实现跨语言、跨平台的数据交换。Protocol Buffers的序列化和反序列化过程可以通过以下公式表示：

• 序列化(M)=Encode(M)
• 反序列化(M)=Decode(M)
  其中，$M$ 是数据结构，$Encode$ 和 $Decode$ 分别表示序列化和反序列化操作。

RPC调用：

gRPC的RPC调用过程可以分为以下步骤：

• 客户端通过Protocol Buffers序列化请求数据，并使用HTTP/2发送请求。
• 服务器接收请求，使用Protocol Buffers反序列化请求数据。
• 服务器执行RPC方法，并将结果序列化为Protocol Buffers格式。
• 服务器使用HTTP/2发送响应给客户端。
• 客户端使用Protocol Buffers反序列化响应数据，并处理结果。

1. 通信方式

• RPC:远程过程调用,是一种进程间通信方式。双方建立链接后,一个进程可以直接调用另一个进程的函数。
• HTTP:超文本传输协议,是一种客户端和服务器之间的请求-响应模式。客户端发送请求,服务器返回响应,两者连接后立即断开。

2. 传输协议

• RPC:可以使用TCP或UDP作为传输协议。
• HTTP:使用TCP作为传输协议。

3. 数据格式

• RPC:通常使用自定义的数据格式,比如XML、JSON等。
• HTTP:使用标准的MIME类型,如HTML、XML、JSON、图片等多种格式。

4. 连接方式

• RPC:双方在通信期间会持续连接。
• HTTP:采用无连接的传输协议,每次连接后立即断开,下次通信需要重新建立连接。

5. 应用场景

• RPC:适用于内部系统集成,提供服务的调用和响应。
• HTTP:适用于Web应用,网页访问和文件传输。

总结一下

• RPC是一种进程内通信机制,HTTP是一种网络应用协议。
• RPC使用TCP或UDP,HTTP只使用TCP。
• RPC使用自定义的数据格式,HTTP使用标准MIME类型。
• RPC是持续连接,HTTP是短连接。
• RPC用于内部集成,HTTP用于Web应用。

伊对

1. 项目，活动营销平台，感觉没有什么技术难点。。。
2. slice 底层实现是什么，源代码里面有哪些结构，是否是线程安全的
3. sync.map 怎么实现的？为什么他是线程安全的，做了哪些处理
4. redis zset，是什么数据结构，redis怎么存的
5. redis 大key问题？
6. mysql 慢查询怎么解决？除了索引（创建合适的索引和修改语句）+数据量 还有哪些方法？
7. go 内存泄漏？ 哪些情况会产生内存泄漏
   1. 内存泄漏可能是因为长期运行的后台服务，或者是因为对象没有被适当地清理。
   2. 比如写入超过channel缓冲区间的 goroutine，但是没有人消费，后续写入全部阻塞
   3. 比如读取channel数据时，由于写入端已经执行完毕，造成饥饿阻塞
   4. 多个协程由于通信问题造成死锁
   5. 某些链接句柄采用了无限循环的方式来保证链接成功
      解决方法：
   6. 检查代码中是否有全局变量或长生命周期对象持有小对象的引用，导致小对象不能被垃圾回收。
   7. 确保使用了智能指针（如sync.Pool）来管理共享资源的生命周期。
   8. 使用工具如go tool pprof分析内存使用情况，找出内存泄漏的位置。
   9. 定期重启服务以清理内存中的无用数据。
   10. 如果使用了第三方库，确保它们在使用后释放所有资源。
   11. 在代码中使用defer语句释放资源，如文件句柄、数据库连接等。
   12. 如果可能，使用上下文（Context）管理和取消长时间运行的操作，以便在操作完成前取消，释放资源。

题：283 移动0 改为 移动target；移动至末尾改为移动至前面

给定一个字符串str，返回字符串中字母顺序最大的而且同时在字符串中出现大写和小写的字母。 如果不存在这样的字母，返回‘~‘。
请返回大写字母
|str|<=1000
‘aAbBcD’ 返回 B

leetcode 931

需要自己写输入输出

昆仑万维

1. gc流程？gc触发时机？
2. channel底层实现？
3. mutex底层实现？ 自旋？
4. mysql 多主多从？
5. raft协议，怎么同步日志？脑裂？怎么解决？
6. Kafka 为什么不支持读写分离？

leet 71
leet 三数之和

Go channel mutex map slice 源码解析 check
Go gc gmp check
mysql B+树
redis raft
kafka
elasticsearch
etcd
grpc
zookeeper

微服务拆分。服务治理（服务发现，管理配置？流量控制，日志监控？容错容灾？）
网络协议：tcp/ip，http，
高并发，高可用，数据一致性

dau 1-2w 上课人数，绘本 20w+
广告位：十几个位置 乘 dau 差不多 百万级别 qps；活动高峰期总参与差不多百万，日均大概能有10-20w，任务接口大概10-20个，综合起来差不多大几百万qps
相关系统 差不多 4核8g，4实例

区块链
1.接口加密怎么做
2.https是安全的么？
3.map为什么是线程不安全的，添加kv的流程是怎么样的？
4.channel区满，剩下阻塞状态的 routine 是怎么调度的？
5.redis 大key
6.go内存对齐
7.mysql B+树
8.雪崩，穿透（互斥锁 + 空缓存；布隆，但是怎么给所有接口加？）是什么？怎么解决？
9.kafka为什么读取比较快？
10.10个G的手机号，内存1G，怎么排序？

newstart 做企业erp的，说是tob但是有点像外包了
1.go for 和 for range 有什么区别？哪个好？
2.go context 过期、复制
3.go slice底层有哪些结构？ 扩容怎么扩的
4.做工资报表，有一批人员，有一批第三方考勤数据，有一批历史工资数据。你会怎么设计数据库？

区块链
接口怎么加密？可以用类似 sign ，对接口参数前后端同时加密对比
https 安全么？抓包？
k8s 崩溃了 有什么恢复手段？自动重启靠什么？
map 为什么线程不安全？ 扩容不是原子性
channel 10缓冲区，100 协程，写满了以后，阻塞的协程会被调度到哪里？归谁管？
redis 大key 问题。kv 中的 v 大，主因还是在于 redis 中 string 类型是用 sds 结构存储，最大一块内存区是 128k，更大的 value 会造成不连续的磁盘存储，影响取值速度；另一个会影响io，但相对不是主要原因
kafka 为什么会快呢？因为他的存储是在一段连续的区域
go 内存对齐
tidb 用的底层是啥？
mysql b+树，叶子节点存在哪里
缓存雪崩？
击穿怎么解决？
10个G的手机号文件，内存1个G，怎么排序？：拆文件，然后可以根据手机号特性，排序第一位第二位，分别放到不同的文件内

阿里：
1.服务拆分 原则 为什么要拆 方法论 颗粒度的粗细 数据一致性 上线之后遇到的问题
2.mongo mysql tidb 有什么优劣
3.kafka pulsuar 有什么优劣
4.数据库迁移遇到过哪些问题 怎么解决的
5.幂等 如何设计
6.给一个视频评论页面，数据库如何设计 索引 缓存
7.二分查找一个小于X的最大数
8.ES的原理

conviva:
1.网址敲了之后会发生什么
2.为什么用tidb
3.数据统计怎么做的
4.算法题 有向无环图求经过三个点的路径总数

旷视：
1.写一个结构体的快排
2.append的第二个参数是什么
3.append了之后会发生什么
3.用var 初始化一个slice 容量有多大 占多少字节
4.随机写一个leetcode中等难度的题

作业帮
1.讲项目，问了问活动数据
2.压力测试怎么做的
3.怎么避免高并发的请求到数据库（我讲了缓存）
4.数据迁移怎么做的？
5.算法题：不重叠的区间
6.go interface 能不能比较？
7.go 协程为什么快？

海纳AI
1.打开文件 应该是打开了才关，没打开不用关
2.for range 是复制出来的
3.协程传参
4.你写代码的层级架构是什么样
5.update where 如果没有索引会发生什么 跟隔离级别有关系吗
6.如何保证数据库和缓存的一致性：
读缓存失败读sql的时候同时更新缓存
对于更新频繁且一致性要求高的场景：更新时先更新缓存，再同步更新sql
更新频繁但是一致性要求低：优先更新缓存，异步更新sql
事务方式双写
使用乐观锁 + 版本控制
7.缓存雪崩的解决办法
8.限流是怎么做的 令牌桶算法 有什么特点
控制请求速率
定时生成令牌，请求需要拿取令牌来执行
漏桶算法：未满入桶，定速漏出来执行
9.假设有一场几十万人的在线考试，如何做到数据持久化数据一致性和高可用
10.什么是k8s的hpa
11.这种场景下redis和数据库的一致性
12.假如有一个表有几百个字段 这时候怎么办

进程，线程，协程的区别
进程间怎么通信
http，socket，rpc 概念和区别？优缺点
微服务怎么分的
raft

n个数，任取 0-k 个求和，求有多少种可能的结果

与爱为舞

项目
微服务
数据库
redis
es
kafka

缓存怎么做的
消息触达平台 - kafka - 延时队列，
mysql 数据怎么落到磁盘上的
前后端加密 session 鉴权怎么做的
服务治理
dns 和 ip 怎么弄得？如果是自建站，是什么流程
redis 相关结构底层 跳表，压缩表，跳表怎么确定层级
由概率问到了项目里面的抽奖

tcp和udp区别
TCP 面向连接（如打电话要先拨号建立连接）提供可靠的服务，UDP 是无连接的，即发送数据之前不需要建立连接，UDP 尽最大努力交付，即不保证可靠交付。
UDP 具有较好的实时性，工作效率比 TCP 高，适用于对高速传输和实时性有较高的通信或广播通信。
每一条 TCP 连接只能是一对一的，UDP 支持一对一，一对多，多对一和多对多的交互通信。
UDP 分组首部开销小，TCP 首部开销 20 字节，UDP 的首部开销小，只有 8 个字节。
TCP 面向字节流，实际上是 TCP 把数据看成一连串无结构的字节流，UDP 是面向报文的一次交付一个完整的报文，报文不可分割，报文是 UDP 数据报处理的最小单位。
UDP 适合一次性传输较小数据的网络应用，如 DNS，SNMP 等。

华为二
go map 底层结构
gc 写屏障
gmp
看过哪些源码？讲讲 slice
go 性能分析工具和方法
为什么要加 redis 这一层，为什么他们快？

什么情况下会存在分布式锁误删的情况

docker 多实例，服务发现 etcd，负载均衡，hpa（自动伸缩），docker file
监控 普罗米修斯、心跳包。限流（令牌桶） 熔断，降级（用的什么中间件）

服务怎么保证稳定性和可用性：报警，服务等级（报警标准），慢查询，监控
微服务设计方式，分区部署，故障隔离
注意流量控制和负载均衡
实例数量自动伸缩 and 服务降级
数据容错和备份
定期健康检查、心跳包
普罗米修斯监控（CPU，内存，堆栈，磁盘使用，请求数，错误率，慢查询统计，数据库连接数量，数据库响应时间，接口响应时间）
日志和钉钉报警，
持续集成和持续部署
身份验证和授权等
性能优化：缓存 and sql

线上有没有经历过内存泄漏，怎么解决？发现（监控指标，堆数量，）， + 定位 + 解决

在Go语言的线上应用中，内存泄漏虽然不常见，但确实可能发生，特别是在高并发和长期运行的服务中。以下是一些常见的内存泄漏问题及其解决方法：

常见内存泄漏原因

1. 长生命周期的对象持有短生命周期对象的引用：

   • 描述：全局变量、单例模式等长生命周期对象持有短生命周期对象的引用，导致短生命周期对象无法被垃圾回收（GC）。
   • 解决方法：尽量避免使用全局变量，或在使用完毕后及时将引用置为nil。

2. 未关闭的Goroutine：

   • 描述：未正确关闭的Goroutine会继续占用内存。
   • 解决方法：确保在适当的时机通过通道（channel）或上下文（context）关闭Goroutine。

3. 未释放的资源：

   • 描述：未正确关闭文件、数据库连接等资源，导致内存占用。
   • 解决方法：使用defer语句确保资源在使用完毕后被正确关闭。

4. 缓冲区无限增长：

   • 描述：使用缓冲区（如slice、map）时，未对其增长进行限制，导致内存占用不断增加。
   • 解决方法：对缓冲区大小进行合理限制，并定期清理过期或无用的数据。

检测内存泄漏

1. pprof工具：

   • Go自带的pprof工具可以用来检测内存使用情况和内存泄漏。
   • 使用方法：

     import (
         "net/http"
         _ "net/http/pprof"
     )
     
     func main() {
         go func() {
             log.Println(http.ListenAndServe("localhost:6060", nil))
         }()
         // 其他代码
     }

     运行应用后，可以通过http://localhost:6060/debug/pprof/heap查看内存使用情况。

2. go-torch工具：

   • 用于生成火焰图（flame graph），帮助分析Goroutine和内存分配。
   • 使用方法：

     go-torch -u http://localhost:6060 -f torch.svg

   • 生成的torch.svg可以用浏览器打开查看内存分配情况。

解决方法

1. 定期检查和优化代码：

   • 定期进行代码审查，确保所有资源都在使用完毕后被正确释放。
   • 对长生命周期的对象进行检查，确保不会持有不必要的引用。

2. 使用上下文管理Goroutine：

   • 通过context包管理Goroutine的生命周期，确保在需要时正确关闭Goroutine。
   • 示例：

     func worker(ctx context.Context) {
         for {
             select {
             case <-ctx.Done():
                 return
             default:
                 // 执行任务
             }
         }
     }
     
     func main() {
         ctx, cancel := context.WithCancel(context.Background())
         go worker(ctx)
         // 其他代码
         cancel()  // 关闭Goroutine
     }

3. 限制缓冲区大小：

   • 对slice、map等缓冲区进行合理大小限制，避免无限增长。
   • 定期清理过期或无用的数据，确保内存使用不会不断增加。

4. 使用内存分析工具：

   • 定期使用pprof和go-torch等工具进行内存分析，及时发现和解决内存泄漏问题。

通过以上方法，可以有效检测和解决Go语言中的内存泄漏问题，确保线上服务的稳定运行。

k8s

kafka 线上有没有遇到什么问题？怎么解决的？
消息堆积：消费者并发处理，消费者自主转发再消费，优化消费逻辑，增加消费者服务实例和 kafka 分区
kafka broker宕机：利用多副本机制，确保宕机时仍有数据可用；定期监控和维护
磁盘空间不足：定期清理过期消息；增加存储或者拓展集群；优化消息存储策略
数据丢失：确保所有副本确认消息接收；启用消息日志压缩和快照功能，保证数据恢复

es

高内聚低耦合，

update where 不走索引 和隔离级别有关么？

项目数据？怎么造一下？亮点
排行榜，@马哥
奖励库存

go routine有没有遇到什么问题
panic 传播
内存泄漏
过量创建
死锁
并发读写造成数据竞争

微服务的层级结构是怎么划分的？架构设计
api网关层：接入 http 接口，处理 post get 等请求，请求转发给相应的微服务，处理某些数据整合逻辑
分为内部接口和外部接口，可能会涉及到不同的鉴权和身份，需要互相隔离
服务层：实现业务逻辑，提供核心功能
数据层：与数据库交互，一般这一层会放到服务层内部
基础运维层：

golang 的缺点？？
不支持泛型
错误处理需要层层收集和显示处理
第三方库待完善
gc 的 stw

mysql 数据怎么 放到磁盘里的

B+ 多路查找树是怎么构建的？
那条数据构建出来的 b+ 树有多高？
二级索引和一级索引的区别？

负载均衡算法?

ab测试原理

cpu跑多少并发量

map 为什么不安全

kafka 为什么会重复消费，
partition 和 消费组的关系？
为什么消息要均分到 partition 上
mysql 有哪些锁？都是怎么实现的？
有哪些索引，外键和主键的区别，联合索引是怎么存的？为什么要弄联合索引这个东西？最左匹配是什么原理？
mysql 分库分表大概的数量级？
zset 做排行榜是怎么排序的？

kafka 的同步方式？kafka 写入是否是顺序的？
redis 持久化？宕机了怎么恢复数据

字节
一面
自我介绍
讲一个感觉技术难度比较高的，重点介绍下项目背景和你的角色
题的话就是 https://leetcode.cn/problems/er-wei-shu-zu-zhong-de-cha-zhao-lcof/description/
问了最左匹配，然后讨论下具体原理
redis zset 具体结构，问 zrange 是怎么查出来数据的。讲完结构还问了查询复杂度。
主播订阅场景：有订阅周期，怎么设计用户订阅表？订阅失效怎么修改状态？

二面
讲项目的架构设计，需求是什么，怎么分模块设计的
会问服务器数量和qps
mysql acid 具体怎么保证的，持久性怎么实现的？为什么需要redolog，为什么不直接把数据刷盘
系统设计：订单表，日两千万，怎么存？我答分库分表，问怎么分；按照用户查询订单列表怎么查
题：leet3

AI 大模型应用落地 AI口语教练 AI虚拟角色社交 这些东西 然后围绕上面提到的东西思考一下 看一下邮件里那个公司介绍的文档
什么是AI agent 什么是RAG 通用的应用落地一般是怎么做的 然后发散性的思考就行了 就是用GPT教法国人学英语 东西不难
![[Pasted image 20240623123910.png]]

Detailed Analysis of Work Experience (Continued)

北京读我科技有限公司

资深服务端开发工程师 (Go)
2019.02 - 2023.10

重构转介绍节点奖励平台

1. 重新梳理了转介绍双方的映射关系，奖励的配置、更新以及发放等多种规则。

   • Problem Identified: Needs more specific methodology and quantification.
   • Improved Version: 重构了转介绍节点奖励平台，通过重新梳理映射关系和优化奖励配置，实现奖励发放效率提升50%。

2. 对多表多关联的历史数据进行迁移，并完善了迁移算法实现与验证、风险评估、数据备份、实时双写、线上实时报错与熔断、并发压力测试、数据比对、操作实施方案制定等任务。

   • Problem Identified: Very detailed, consider breaking into multiple points.
   • Improved Version:
     • 实施了多表多关联的历史数据迁移，优化了迁移算法并进行了风险评估和数据备份。
     • 确保数据迁移的准确性和系统稳定性，通过实时双写和并发压力测试等手段提高了迁移效率和安全性。

一对一增长业务

1. 项目负责人，负责一对一业务线增长业务的业务模型设计、接口交互设计以及日常需求的迭代。

   • Problem Identified: Lacks quantification and more detailed accomplishments.
   • Improved Version: 作为项目负责人，设计并迭代一对一业务线的增长业务模型和接口交互设计，带领团队实现增长率提高20%。

2. 承接一对一和绘本等多个业务线的节日节点和大型活动：新年，618，教师节，双11等大型活动，高效稳定地完成了预期的促活、转介绍、促课消等目标。

   • Problem Identified: Needs specific examples of achievements and methodology.
   • Improved Version: 组织并执行了一对一和绘本业务线的新年、618、教师节、双11等节日活动，实现了促活、转介绍和促课消目标，提高用户参与率30%。

研发消息触达配置平台

1. 规范不同触达方式，提升研发效率，支持运营侧个性化触达方案。

   • Problem Identified: Lacks specific achievements and quantification.
   • Improved Version: 开发了消息触达配置平台，规范不同触达方式，提高研发效率50%，支持个性化触达方案，实现用户触达率提升25%。

2. 通过 Kafka 进行系统间通信，同时支持了多业务、万级别 TPS 的用户触达。

   • Problem Identified: Lacks specific methodology and impact.
   • Improved Version: 利用 Kafka 进行系统间通信，支持多业务和万级别 TPS 的用户触达，提高系统通信效率和稳定性。

搭建海报平台

1. 针对用户拉新中重要的海报分享行为搭建，为运营同学高效快速更新海报内容及落地页活动提供支持。

   • Problem Identified: Needs more quantification and specific achievements.
   • Improved Version: 搭建了海报平台，优化用户拉新分享流程，支持快速更新海报内容和活动页面，提高新用户转化率20%。

2. 对新老用户扫码行为进行数据监控与识别，提升 leads 激活效率；与营销活动结合，利用识别结果协助优化拉新路径。

   • Problem Identified: Needs specific impact and achievements.
   • Improved Version: 实施了新老用户扫码行为的数据监控与识别，提高 leads 激活效率30%，优化用户拉新路径。

搭建活动营销平台

1. 抽象总结承接的各种营销活动，将其拆分为：任务，抽奖，奖品发放，数据统计，分享，签到，问卷，团购，基础配置等多个组件。

   • Problem Identified: Very detailed, consider breaking into multiple points.
   • Improved Version:
     • 构建了活动营销平台，将活动拆分为多个组件，提高活动配置灵活性和开发效率。
     • 实现活动上线速度提升50%，支持多项百万级并发活动，提高系统稳定性和性能。

2. 组件间使用消息队列进行通信，打通了业务节点、用户标签、用户动作、前端配置化体系、数据中心等多个系统、多个业务线的路径。

   • Problem Identified: Lacks specific achievements and quantification.
   • Improved Version: 使用消息队列进行组件间通信，打通多个系统和业务线路径，提高数据处理效率和系统整合能力。

搭建广告投放平台

1. 抽象和整理了公司各 app 30+ 投放位置的多种展示模式；支持用户标签、访问渠道、业务线、版本等多种筛选模式；支持静默期、投放区间、投放频率等等多种细分功能；结合前端，支持投放数据上报与检测。

   • Problem Identified: Very detailed, consider breaking into multiple points, lacks specific impact.
   • Improved Version: 搭建了广告投放平台，支持多种展示和筛选模式，提高广告投放灵活性和效率，实现广告点击率提高20%。

2. 采用内存 - Redis - TiDB 三级缓存结构支持高并发访问。

   • Problem Identified: Needs more specific impact and achievements.
   • Improved Version: 采用三级缓存结构，支持高并发访问，提高系统响应速度和稳定性。

3. 平台上线3个月内对接至全部 app 展示位置，运行稳定，最高支持百万级别的用户访问，在提升业务侧配置效率的同时，协助搭建运营模型和升级运营策略。

   • Problem Identified: Needs specific impact and more detailed accomplishments.
   • Improved Version: 平台上线3个月内完成对接，运行稳定，支持百万级用户访问，提高配置效率和运营策略。

负责第三方广告商的对接和维护

1. 对接小红书、华为、头条、OPPO、百度等多个广告商。

   • Problem Identified: Needs more specific impact and achievements.
   • Improved Version: 对接小红书、华为、头条、OPPO、百度等广告商，提高广告投放效果，实现广告转化率提升20%。

2. 针对注册、登录、业务意向、付款等关键节点进行监控和数据上报，生成数据漏斗协助运营优化投放方案。

   • Problem Identified: Needs more specific methodology and impact.
   • Improved Version: 监控关键节点并生成数据漏斗，协助运营优化广告投放方案，提高投放效果和转化率。

领导五人团队开发增长业务相关项目

1. 把控研发进度，合理分配人员工作，确保项目顺利进行。
   • Problem Identified: Lacks specific achievements and quantification.
   • Improved Version: 领导五人团队开发增长业务项目，合理分配工作，确保项目按时完成，带领团队实现增长目标。

搭建分销系统

1. 管理和维护第三方分销员，管理和维护分销商品，管理和维护分销员与用户的映射关系，并提供海报、链接、分享话术等相关分销工具。
   • Problem Identified: Needs more specific achievements and quantification.
   • Improved Version: 搭建分销系统，管理分销员和商品，提供分销工具，提高分销效率和转化率，实现分销目标。

负责搭建背诗小程序后台

1. 支持后台古诗文导入；支持用户分句分段多种背诵模式。

   • Problem Identified: Lacks specific achievements and quantification.
   • Improved Version: 开发背诗小程序后台，支持古诗文导入和多种背诵模式，提高用户学习效率和参与度。

2. 提供好友排位、拉新分享等营销功能。

   • Problem Identified: Lacks specific achievements and quantification.
   • Improved Version: 提供好友排位和拉新分享功能，提高用户互动和参与度，实现拉新目标。

一对一 CRM 业务

1. 负责 leads 激活的流量管理与提纯，销售路径数据收集与反馈。

   • Problem Identified: Lacks specific achievements and quantification.
   • Improved Version: 负责 leads 激活的流量管理与提纯，优化销售路径数据收集和反馈，提高销售转化率20%。

2. 优化销售数据分配规则；在用户拉新、激活、维护、售卖等节点为销售人员提供数据和工具支持。

   • Problem Identified: Lacks specific achievements and quantification.
   • Improved Version: 优化销售数据分配规则，为销售人员提供数据和工具支持，提高销售效率和转化率