遵义微商城网站建设平台,别人的抖音网站是怎么做的,湖南工程建设监理有限公司网站,个人在线视频播放网站搭建1.你认为什么是操作系统#xff0c;操作系统有哪些功能
os是#xff1a;管理资源、向用户提供服务、硬件机器的扩展 1.进程线程管理#xff1a;状态、控制、通信等 2.存储管理#xff1a;分配回收、地址转换 3.文件管理#xff1a;目录、操作、磁盘、存取 4.设备管理操作系统有哪些功能
os是管理资源、向用户提供服务、硬件机器的扩展 1.进程线程管理状态、控制、通信等 2.存储管理分配回收、地址转换 3.文件管理目录、操作、磁盘、存取 4.设备管理设备驱动、分配回收、缓冲技术 5.用户接口系统命令、编程接口
2.简单linux命令使用top ps netstat df less grep
top: 性能分析工具能够实时显示系统中各个进程的资源占用状况进程 ps列出运行的进程 netstat显示网络状态所有连线的socket df显示系统上的文件系统磁盘使用情况统计 less随机浏览文件支持翻页和搜索 grep用于查找文件里符合条件的字符串或正则表达式 tail看日志最后
3.innodb和myisam区别统计记录的数量会怎么做
区别 1.InnoDB中不保存表的具体行数而MYISAM对是单独存起来的 2.InnoDB是聚集索引数据文件是和索引绑在一起的必须要有主键通过主键索引效率很高。但是辅助索引需要两次查询先查询到主键然后再通过主键查询到数据MyISAM是非聚集索引数据文件是分离的索引保存的是数据文件的指针。 3.InnoDB支持外键而MyISAM不支持。 4.MyISAM类型不支持事务处理等高级处理而InnoDB类型支持myisam强调性能 5.InnoDB支持数据行锁定MyISAM不支持行锁定只支持锁定整个表高并发insertinnodb完胜
全量count操作 myisam中把表的总行数存储在磁盘上直接返回 innodb一条条读出来再加起来因为innodb的事务特性mvcc导致多少行不确定 myisam更快
count带where筛选myisam不一定快了
4.tcp是用什么保证可靠性的
TCP协议主要通过以下七点来保证传输可靠性连接管理校验和序列号确认应答超时重传流量控制拥塞控制。
连接管理 即三次握手和四次挥手。连接管理机制能够建立起可靠的连接这是保证传输可靠性的前提。
校验和 发送方对发送数据的二进制求和取反然后将值填充到TCP的校验和字段中接收方收到数据之后以相同的方式计算校验和并进行对比。如果结果不符合预期则将数据包丢弃。 注意即便二者相等也并不能确保数据包一定是正确无误的基于某些巧合会出现数据包错误但发送端和接收端的校验和相等的场景。
序列号 TCP将每个字节的数据都进行了编号这就是序列号。序列号的具体作用如下能够保证可靠性既能防止数据丢失又能避免数据重复。能够保证有序性按照序列号顺序进行数据包还原。能够提高效率基于序列号可实现多次发送一次确认。
确认应答 接收方接收数据之后会回传ACK报文报文中带有此次确认的序列号用于告知发送方此次接收数据的情况。在指定时间后若发送端仍未收到确认应答就会启动超时重传。
超时重传 具体来说超时重传主要有两种场景数据包丢失在指定时间后若发送端仍未收到确认应答就会启动超时重传向接收端重新发送数据包。确认包丢失当接收端收到重复数据(通过序列号进行识别)时将其丢弃并重新回传ACK报文。
流量控制 接收端处理数据的速度是有限的如果发送方发送数据的速度过快就会导致接收端的缓冲区溢出进而导致丢包……为了避免上述情况的发生TCP支持根据接收端的处理能力来决定发送端的发送速度。这就是流量控制。流量控制是通过在TCP报文段首部维护一个滑动窗口来实现的。
拥塞控制 拥塞控制就是当网络拥堵严重时发送端减少数据发送。拥塞控制是通过发送端维护一个拥塞窗口来实现的。可以得出发送端的发送速度受限于滑动窗口和拥塞窗口中的最小值。 拥塞控制方法分为慢开始拥塞避免快重传和快恢复
5.如果发现cpu飙升怎么排查
线上CPU飙升的问题很常见例如某个活动开始流量突然飙升时 线上系统突然运行缓慢CPU飙升甚至到100%以及Full GC次数过多接着就是各种报警例如接口超时报警等。 top确认进程 -》 top确认线程 -〉 线程hex -》jstack堆栈信息 -〉 jstat gcutil信息 原因 1.内存消耗过大gc次数过多生成大量对象导致溢出也可能system.gc过多 2.耗cpu操作无限递归等 3.死锁 4.大量进程访问阻塞的接口 5.某个线程进入waiting状态导致不可用
6.redis怎么实现去重
基于setSISMEMBER key member 基于bitRedis 的 bit 可以用于实现比 set 内存高度压缩的计数它通过一个 bit 1 或 0 来存储某个元素是否存在信息用userid作为访客偏移网站访客计数setbitgetbitbitcount等 基于hyperloglog实现超大数据量精确的唯一计数基于概率论近似计数12 k左右的内存实现上亿的唯一计数而且误差控制在百分之一左右 基于BloomFilter是利用类似位图或者位集合数据结构来存储数据利用位数组来简洁的表示一个集合并且能够快速的判断一个元素是不是已经存在于这个集合。虽然BloomFilter不是100%准确需要安装插件
7.如果去重的时候查询redis时网络波动导致查超时怎么办
假设场景redis 响应变慢查看日志发现大量 TimeoutException。 大量TimeoutException说明当前redis服务节点上已经堆积了大量的连接查询超出redis服务能力再次尝试连接的客户端redis 服务节点直接拒绝抛出错误。
1.cpu资源竞争要与上层应用进行资源隔离 2.swap导致redis内存交换磁盘关闭swap 3.对于网络波动 a.配置文件优化如timeout时间300stcp-keepalive心跳机制60 b.数据备份和容错主节点和备份节点用sentinel自动故障检测和转移保证可用 c.数据aof持久化避免数据丢失replication同步
8.kafka在什么情况下会导致消息丢失
参考https://huaweicloud.csdn.net/637ee65ddf016f70ae4c905f.html?spm1001.2101.3001.6661.1utm_mediumdistribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Eactivity-1-125605128-blog-131979567.235%5Ev38%5Epc_relevant_sortdepth_1-utm_sourcedistribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Eactivity-1-125605128-blog-131979567.235%5Ev38%5Epc_relevant_sortutm_relevant_index1
1.生产过程丢失网络原因重发解决try catch异常消息表异步任务重试kafka自动重试有次数限制一般手动 2.服务端持久化丢失kafa异步刷盘broker在刷盘前宕了丢失了 每个partition多副本leader和follower加快持久化的性能和安全性ISR OSR AR 3.消费过程丢失offset的概念消费者从partition拉取后本地处理完需要commit一下offset说明消费完成关闭自动commit offset要处理完逻辑后再commit
9.kafka和rabbitmq有什么区别
1.开发语言rabiitmq用erlangkafa用scala和java用于活跃的流式数据大数据量 2.结构不同rabbitmq的broker有exchangebiding和queuekafka的broker有part分区 3.交互式rabbitmq用pushkafka用pull 4.负载均衡rabbitmq单独的loadbalncerkafka用zookeeper对broker和consumer进行管理 5.使用场景rabbit支持消息可靠传递支持事务不支持批量kafka高吞吐内部采用消息的批量处理
10.explain参数 id,select_type,type,possible_key, key,key_len,ref,rows_filtered,extra
11.http报文参数有哪些吗 请求行方法等 请求头部kv对 空行 请求数据 状态行 响应头kv对 空行 响应体
12.消息队列如何保证可靠性和消息幂等性
消费者多次受到信息要保证消费的幂等性 唯一id、分布式锁只有一个消费者消费清单消费状态记录
可靠性 1.异常捕获机制try catch 2.事务机制 3.发送端确认confirm 4.持久化存储 5.消费者ack 6.消息积压的话得进行限流 7.幂等性
13.消息队列优缺点
优点解耦异步削峰 缺点可用性降低挂了、复杂度上升重复、丢失、顺序、一致性
14.接口幂等性如何保证
参考https://www.21ic.com/article/883663.html 幂等性它描述了一次和多次请求某一个资源对于资源本身应该具有同样的结果网络超时等问题除外使用幂等性最大的优势在于使接口保证任何幂等性操作免去因重试等造成系统产生的未知的问题 问题前端重复提交表单用户恶意进行刷单接口超时重复提交消息进行重复消费 影响改成串行降低效率业务复杂 get满足post不满足 实现方法 1.数据库唯一主键的实现主要是利用数据库中主键唯一约束的特性一般来说唯一主键比较适用于“插入”时的幂等性其能保证一张表中只能存在一条带该唯一主键的记录使用分布式id雪花id之类 2.数据库乐观锁实现幂等性多加一个字段作为数据的版本标识多次更新无影响 3.防重 Token 令牌实现幂等性对于点许点击或超时充实提交订单调用方在调用接口的时候先向后端请求一个全局 IDToken请求的时候携带这个全局 ID 一起请求Token 最好将其放到 Headers 中后端需要对这个 Token 作为 Key用户信息作为 Value 到 Redis 中进行键值内容校验如果 Key 存在且 Value 匹配就执行删除命令然后正常执行后面的业务逻辑。如果不存在对应的 Key 或 Value 不匹配就返回重复执行的错误信息这样来保证幂等操作。 要保持检查and删除的原子性使用lua脚本 4.下游传递唯一序列号实现幂等性请求序列号其实就是每次向服务端请求时候附带一个短时间内唯一不重复的序列号该序列号可以是一个有序 ID也可以是一个订单号redis加上过期时间
