作者:寻找另一半哥哥_335 | 来源:互联网 | 2023-08-25 12:54
1、Redis的简单应用及搭建,未做深入学习,简单,目前的情况大概当做跨服务器Session使用,由于项目的原因,未能在项目在大规模应用,涉及到旧项目改造的成本和代码太高。2、MQ
1、Redis的简单应用及搭建,未做深入学习,简单,目前的情况大概当做跨服务器Session使用,由于项目的原因,未能在项目在大规模应用,涉及到旧项目改造的成本和代码太高。
2、MQTT,基于MQTT的消息订阅和发布机制,是很有意思的一个思路,也在项目中实践应用;
3、Nginx,有个需求,需要同一台服务器的webSocket和https使用同一个端口,使用HaProxy死活做不了,使用TCP四层协议的时候,无法向后端透传客户的真实IP地址,使用HTTPS无法自动识别,后来使用NGINX的HTTPS机制,完美实现。
4、重新改造的预发布文件系统监控、SQL脚本批量多服务器执行、负载均衡多服务器代码一键发布;在这半年的时间里,反复验证,已经基本完美,无缺陷、无BUG,保持长时间稳定运行;
5、更进一步认识LINQ、EF框架;有更深刻的了解;
6、对SQL、存储过程写法,应用得比过去更多,场景更变态,更复杂,对自已也算是对不足的一个补充;
7、见识了不同人所写的代码、对系统的设计思路,有优有劣;
8、最近半年,由于现网系统的架构原因,主要基于存储过程编写,同时有很复杂庞大的业务系统,半年时间大约对系统了解也就在50%左右;但是这半年时,经常面对已经经过无数次优化的存储过程、查询和代码,总结了一些优化心得,略做描述,备忘
A:SQL SERVER的跟踪管理器,用于查找reads读的次数超多(通常是未走索引,通过消息里的表扫描可以看出来)、或者du执行时间超过X秒的存储过程,找出来使用SQL查询分析器做分析,寻找和补充索引。
B:新增索引优先考虑对现有索引的优化,考虑能与现有索引兼容的情况;
C:多列索引的场景下,索引前后顺序决定查询条件是否走某个索引,索引列的升序降序,虽然不能体现减少reads或者扫描次数,但确确实实有时候能非常明显的提升查询速度;
D:把不合理的查询方法改正,例如存储过程里相同、消耗时间的结果,多次重复查询;减少为1次;
E:代码里不合理的循环的使用,以某个案例,查询1号到30号的数据,在循环内30次调用存储过程;执行接近60秒;改成直接查询范围1-30号,一次查询拿到全部目标结果,然后在程序代码里再对数据进行加工,分组,耗时降为5秒。
F:SQL里以前很少用到的:Select * Into #temp from ...;update table_1 set x=1 output Insert.ID Into #Temp;等;接下来会继续学习;
G:以前项目里极少、很少用到多表联合查询的场景,和业务、表的设计有关系,现有系统基本上全是这种结构;确实联合查询减少查询次数,能有效明显降低查询耗时,只是业务设计太复杂了,基本架构也设计得不行;库分太多,常常涉及跨库,做跨库事务是个麻烦事。
9、开始学习使用redmine管理项目进度;希望让工作能更科学;面对不同的挑战,以及空降这个事情,外加现有系统和业务的复杂,希望能逐步理清,也能借用这个场景历练自已。面对不同的困境,不断思考解决困难的方法,多实践,多反思。
其它的后续再补充;
整理一点平时的想法,和希望有机会实践的东西:
1、希望自已做一套分布式网关,同时自带API文档、入参校验、签名校验,支持服务间调用、应用化调用、外部业务调用;支持对分布式后端服务代码、程序做自动负载热更新;优先考虑在.NET Core的基础之下进行开发网关系统;
2、整理和再学习微服务架构;
3、用好redis、用活MQTT;或者自已开发一套基于webSocket的发布、订阅系统;多数场景下,可以使用webSocket来替代TCP;
4、思考对现有系统的复杂框架,在许可的条件下,逐步改造成无限扩展的分布式系统的各种方案,相信也许会有机会,或者有合适的启发,能向这个方向去发展;主要是代码量,存储过程的数量,表的数量,以及过去表设计不合理,业务复杂化,但历史遗留问题,虽然很难解决,还是需要不断的想办法。
其它的想到再写吧。