大家好，我是 那个曾经的少年回来了。10年前我也曾经年轻过，如今已步入被淘汰的年龄，但现在幡然醒悟，所以活在当下，每天努力一点点，来看看2024年的时候自己会是什么样子吧，2024年的前端又会是什么样子，而2024年的中国乃至全球又会变成什么样子，如果你也有想法，那还不赶紧行动起来。期待是美好的，但是更重要的是要为美好而为之奋斗付诸于行动。
1、前言
最近正在做的项目上线了，问题很多，有前端的问题也有后端的问题。最近也接触了一点公司的后端，顺便一起简单的总结一下。
- 应用主要是微信小程序和PC后台， 下面是微信小程序的访问
这里是正在使用的人数，应该在11月底的时候可能达到访问使用的高峰，情况好的话可能存在上万人的访问使用。
- 服务器配置 mysql数据库，一主四从 其实我觉得超配了
- 应用服务器的话 现在使用了三台应用服务器作为负载均衡
2、前端
先说一下前端的问题，这里对代码的探讨不做过多的展示，主要简单说明一下技术的实现方案。
2.1、技术选型问题
h5嵌套到小程序的webview,但是又要用到小程序里的地图定位，就需要由H5跳转到小程序的页面，然后要由小程序页面返回到webview中的h5,这里还需要有一个返回值传到h5中，这里我暂时没想到办法，至少我没想到办法回传数据，于是只能简单的写个定时器，不断的通过接口调用，相当于数据的回传刷新了。
这里如果完全是小程序的页面就不会存在这个问题了，不过水饺咱没时间全部用小程序的页面呢？
2.2、表单重复提交问题
由于项目中主要的就是数据的录入，所以出问题最多的就是在表单多次提交，其实也有很多的方法。
- 方法一： 按钮提交时，将按钮设置为加载状态，并不可点击。
- 方法二： 通过pinia保存状态数据，点击保存时对比数据，数据如果未被修改，则不调用接口保存，有效的减少了服务器写入数据的压力。
2.3、缓存问题
由于是h5嵌套到webView的小程序中的，所以有时候明明更新了前端，用户却还是之前的版本，这里想到的办法就是通过nginx 配置 缓存
location /{ alias /usr/local/xxxx; index index.html; add_header Cache-Control no-cache; }
no-cache 协商缓存，每次也去服务器请求，但会进行判断是否是新的资源，如果是旧的资源，则直接返回304使用客户端的缓存。
no-store 相当于每次请求都会从服务器获取前端页面，不会进行缓存。
当然这里其实还存在一个问题，
2.4、其他
当然还存在其他一些小问题，比如用户操作便利性的改进，以及友好的错误提示，首页访问较慢、qiankun自子应用加载慢的问题都需要进一步研究解决 等等。
3、后端
由于我也参与了一些后端接口的工作，对整个前后端的情况都有所了解。
3.1、重复数据
由于前期时间确实比较紧张，准备不足，导致程序存在一些问题，经过排查发现，在导入数据的时候没有判断数据的唯一性，导致数据重复。这个算是一个bug，目前已经修复了。
3.2、数据延迟
由于高峰期存在接口10秒都没有提交成功的情况，后来发现mysql事务中的查询存在比较大的耗时，经过调整添加索引修改查询条件，不进行全表扫描，目前观察不存在事务高峰期数据并发导致Mysql数据库CPU拉满的情况。
3.3、日志处理
应用中存在记录日志文件过大，并发量大的时候，导致频繁插入，而且文件越大插入速度必然很慢，这里做了文件大小限制，将大小设置未10M，很小了，速度非常快。并且在应用中对日志类型也就是写入日志的频次进行 修改，没有必要的日志进行了移除。
3.4、用户身份
通过调试发现，每次接口调用，用户身份信息都会重新获取，而且要请求mysql，这个看了一下并不是那么容易处理，暂时还没解决。这里可以进行缓存处理，但是发现有一点复杂，后面有时候肯定还是要处理的。
4、 总结
最近刚好在重装自己的办公电脑，以及个人华为云服务器，总结还需要加强的一些知识点
- linux磁盘挂载问题
- mysql数据备份问题
- 服务器扩容前的处理事项、应用备份、以及相关配置文件
- 服务器扩容后的检查工作、磁盘状态、应用、数据库、redis等正常使用
- mysql数据库索引在查询方面真的太重要了
- mysql 主从同步、读写分离
- 应用层的负载均衡
我的个人博客：vue.tuokecat.com/blog
我的个人github：github.com/aehyok
我的前端项目：pnpm + monorepo + qiankun + vue3 + vite3 + 工具库、组件库 + 工程化 + 自动化
不断完善中,整体框架都有了
在线预览：vue.tuokecat.com
github源码：github.com/aehyok/vue-…
