分类目录归档:技术交流

同步调度和异步调度

简单来说有的东西是不允许同时修改的。是要按流程一步一步执行下去的。

但是其实现在重点讲下异步调度,因为很多比如某些api采集,他们是完全独立的。但是因为需要轮询,之前是把所有的采集接口的操作都放在同一个函数里面。然后由shell脚本进行轮询调度。结果除了很多次的幺蛾子。比如其中一个出错,那么所有的采集都凉凉,除非要做好比较完美的出错处理,还有采集接口的状态判断的操作才可能不导致一个凉凉,全部凉凉的事情的发生。所以分开单独调度比较好。那么如果十几个接口的轮询采集和调度都使用shell,那么开启和关闭,还有测试调试每个接口的采集状态什么的时候那么就有的操蛋了。

之前也用过xxljob这个产品,不过不得不说java的产品的比较吃资源一点。以前在成本比较不允许的情况下一个,相当于一个定时器每个月4H4G的配置还经常有点吃力还是有点无语的。后面可以忽略不计的时候才能说,东西好用就可以了。不然以前至少有十次以上因为日志满了导致的问题吧。 因为自己不熟悉java,而xxljob的管理者每次都没有完美处理这个问题导致了有点害怕xxljob,不然那个东西倒是挺出名挺好用的。

运维管理之jumpserver

管理多年的服务器,做多了一个人顶一个技术部门的事情。所有的东西也都在自己一个人手里。一两千万的业务可能就几台服务器就够了。专业一点,业务大点,随便都是十几二十台服务器。以前什么excel记录服务器信息,什么专门文件夹管理服务器信息什么的。管的倒是不算吃力,但是现在ubuntu , centos,windows,ubuntu多个系统。一个人在多台电脑,多个操作系统之间进行作业。那么这种管理信息的方式的弊端立马就出来了。

很多东西都不是难不难的问题,可能价值极高,但是只是一句话。以前都不知道这种东西,这两年接触了,但是一直都没用上。甚至之前一直还想自己开发一个小系统专门存放管理服务器信息的。刚好有朋友咨询他们被黑的事情。也提到他们用jumpserver运维。也借这个契机用用了。

首先就是先安装了。买了广州的服务器,然后git clone到服务器上,总结一点就是实在是慢。

centos7自动yum -y update ???

linux升级系统一般都没有导致过问题。碰到过的是升级之后gitlab打不开的情况。那个gitlab直接凉凉了,还好没有重要的东西那个gitlab。不然那个时候花了不少时间也没有把gitlab修复起来。如果那个是重要的gitlab,那么就很凉凉了。

数据库服务器日志占用过大维护

也算是为了省钱,也算是为了极端压榨技术。以前很多年很少对数据库有一个定期的或者自动的一个维护。现在使用的是一个centos7 mysql 20G硬盘的数据库服务器。人工看宝塔,空间已经占用80%以上了。一般centos7系统占用不到3G。看了数据库大小加起来2.2G,但是总占用空间却已经达到了17G,剩下的空间不多了。因为是用宝塔面板搭建了数据库服务器。去后台关闭了一下二进制日志,开启二进制日志,一下子空间占用少了5G左右。这个是偷懒做法。

https://blog.csdn.net/qq_34924407/article/details/80556557

测试与另外一个服务器端口的连通性

多年来碰到了大大小小的漏洞事件也是漏怕了。所以对端口都是严格限制访问ip的。那么有的时候会有一些无法连接什么的报错。比如某业务服务器连接到数据库服务器是走内网的。开了端口还有ip授权的,但是laravel还是提示连接失败,那么这个时候就要看看这台业务服务器访问数据库服务器内网ip的3306端口是否正常连接了。

使用telnet ,以前是windows,经常机器是没有telnet的,还要各种图形界面找telnet。用了ubuntu ,centos ,macos 就直接可以用,或者一键安装方便多了。

telnet x.x.x.x 3306

root@debugger:~# telnet 10.1.13.87 3306
Trying 10.1.13.87…
Connected to 10.1.13.87.
Escape character is ‘^]’.
N
5.7.25-log��
sy-4<-
g4511{Oj<3mysql_native_password

从另外一个角度来说,数据库服务器端口如果公开暴露在网络上,一个telnet就可以被批量扫描到。而且直接爆出了数据库的版本,如果这个版本突然爆出漏洞,那么将是何等的危险,非常容易凉凉。

redis是什么,为什么要用redis?

Redis的的是完全开源免费的,遵守BSD协议,是一个高性能的键值数据库。是当前最热门的的的NoSql数据库之一,也被人们称为数据结构服务器。
那为什么要用Redis的的的呢?原因很简单,快!

这个问题在大并发,高负载的网站中必须考虑.redis数据库中的所有数据都存储在内存中。由于内存的读写速度远快于硬盘,因此Redis的的的在性能上对比其他基于硬盘存储的数据库有非常明显的优势。

项目中使用Redis的的的,主要是从两个角度去考虑:性能状语从句:并发。当然,Redis的的的还具备可以做分布式锁等其他功能,但是如果只是为了分布式锁这些其他功能,完全还有其他中间件代替,并不是非要使用Redis的的的。因此,这个问题主要从性能和并发两个角度去答。

性能:
我们在碰到需要执行耗时特别久,且结果不频繁变动的SQL,就特别适合将运行结果放入缓存,这样,后面的请求就去缓存中读取,请求使得能够迅速响应。

并发:
在大并发的情况下,所有的请求直接访问数据库,数据库会出现连接异常。这个时候,就需要使用的的Redis的做一个缓冲操作,让请求先访问到的Redis的的,而不是直接访问数据库。

redis的的的的优势:1,运行在内存,速度快官方号称支持并发11瓦特读操作,并发8瓦特写操作,可以说是相当彪悍了。

2,数据虽在内存,但是提供了持久化的支持,即可以将内存中的数据异步写入到硬盘中,同时不影响继续提供服务

3,支持数据结构丰富(string(字符串),list(链表),set(集合),zset(sorted set – 有序集合))和Hash(哈希类型,md5加密出来的那个串)


作者:浮笙
来源:CSDN
原文:https://blog.csdn.net/qq_41846563/article/details/81203773
版权声明:本文为博主原创文章,转载请附上博文链接!