做婚纱网站是怎么确认主题,有谁知道哪个网址,海口市建设局网站,品牌设计公司宣传画册redis中大key引起的问题
1、阻塞请求 Big Key对应的value较大#xff0c;我们对其进行读写的时候#xff0c;需要耗费较长的时间#xff0c;这样就可能阻塞后续的请求处理。Redis的核心线程是单线程#xff0c;单线程中请求任务的处理是串行的#xff0c;前面的任务完不成…redis中大key引起的问题
1、阻塞请求 Big Key对应的value较大我们对其进行读写的时候需要耗费较长的时间这样就可能阻塞后续的请求处理。Redis的核心线程是单线程单线程中请求任务的处理是串行的前面的任务完不成后面的任务就处理不了。
2、内存增大 读取Big Key耗费的内存比正常Key会有所增大如果不断变大可能会引发OOM内存溢出或达到redis的最大内存maxmemory设置值引发写阻塞或重要Key被逐出。
3、阻塞网络 读取单value较大时会占用服务器网卡较多带宽自身变慢的同时可能会影响该服务器上的其他Redis实例或者应用。
4、影响主从同步、主从切换 删除一个大Key造成主库较长时间的阻塞并引发同步中断或主从切换。
redis如何妥善处理大key问题 要解决Big Key问题无非就是减小key对应的value值的大小也就是对于String数据结构的话减少存储的字符串的长度对于List、Hash、Set、ZSet数据结构则是减少集合中元素的个数。
1、对大Key进行拆分将一个Big Key拆分为多个key-value这样的小Key并确保每个key的成员数量或者大小在合理范围内然后再进行存储通过get不同的key或者使用mget批量获取。
2、对大Key进行清理对Redis中的大Key进行清理从Redis中删除此类数据。Redis自4.0起提供了UNLINK命令该命令能够以非阻塞的方式缓慢逐步的清理传入的Key通过UNLINK你可以安全的删除大Key甚至特大Key。
3、监控Redis的内存、网络带宽、超时等指标通过监控系统并设置合理的Redis内存报警阈值来提醒我们此时可能有大Key正在产生如Redis内存使用率超过70%Redis内存1小时内增长率超过20%等。
4、定期清理失效数据如果某个Key有业务不断以增量方式写入大量的数据并且忽略了其时效性这样会导致大量的失效数据堆积。可以通过定时任务的方式对失效数据进行清理。
5、压缩value使用序列化、压缩算法将key的大小控制在合理范围内但是需要注意序列化、反序列化都会带来一定的消耗。如果压缩后value还是很大那么可以进一步对key进行拆分。
zset底层数据结构有了解吗
zset的两种数据结构压缩表ziplist 当redis插入第一个元素时同时满足以下条件就会以ziplist创建跳表 节点数量128 可通过server.zset_max_ziplist_entries设置 节点的长度64可通过server.zset_max_ziplist_value设置 当选择用ziplist实现zset后以后插入的节点若不满足以上任一个条件就会转为skiplist ziplist 编码的 Zset 使用紧挨在一起的压缩列表节点来保存第一个节点保存 member第二个保存 score。ziplist 内的集合元素按 score 从小到大排序其实质是一个双向链表。虽然元素是按 score 有序排序的 但对 ziplist 的节点指针只能线性地移动所以在 REDIS_ENCODING_ZIPLIST 编码的 Zset 中 查找某个给定元素的复杂度为 O(N)。 跳表skiplist
跳表的本质是一个多层链表它能快速地查询、插入、删除【时间复杂度均为O(logn)】所以它的查询速度媲美平衡二叉树而且它的数据结构比平衡二叉树简单结构示意图如下: 查询过程时间复杂度为O(logn) 前向遍历 从当前层的当前节点开始沿着水平方向向前遍历直到找到当前层中下一个节点的值大于或等于要查找的值或者到达当前层的末尾。如果到达当前层的末尾并且当前层不是最底层则下降到下一层然后从下一层的相应节点继续向前遍历。 垂直下降 当在某一层找到的节点值大于或等于要查找的值时或者已经到达当前层的末尾则移动到下一层对应的节点即通过节点的向下指针。在新的层上重复步骤2的前向遍历。 查找结束 当到达最底层并且找到的节点值等于要查找的值时查询成功。如果在最底层遍历到的节点值不等于要查找的值则说明跳表中不存在该值查询失败。
zset底层为什么使用skipList不使用B树请对比分析原因
redis设计本身使用的是极简思想跳跃表的操作比二叉树简单不需要考虑平衡实现起来也简单,我觉的这个是重点redis是纯内存操作不需要考虑磁盘IO的次数一个*header可以理解为一个数据页只不过是在内存里MySQL为了持久化需要考虑磁盘IO利用数据页系统缓存减少磁盘的操作顺序
手撕sql一个表连接的题目题目记不太得
基于sql题目先问你了解索引吗索引为什么快索引的底层数据结构选型问题 基于sql题目问你认为应该把索引建立哪一几列为什么这么做 基于sql题目问你什么情况下索引会失效如何避免这种情况 union和join的区别
JOIN操作符用于根据两个或多个表之间的相关列来合并这些表的数据。UNION操作符用于合并两个或多个SELECT语句的结果集。合并后的结果集会去除重复的行。UNION默认去除重复行而UNION ALL保留重复行。JOIN不会去除重复行它基于关系返回匹配的行。
了解tcp和udp吗区别是什么实际应用场景有什么不同
TCP 和 UDP 区别
1. 连接
TCP 是面向连接的传输层协议传输数据前先要建立连接。UDP 是不需要连接即刻传输数据。
2.服务对象
TCP 是面向连接的传输层协议传输数据前先要建立连接。UDP 是不需要连接即刻传输数据。
3.可靠性
TCP 是面向连接的传输层协议传输数据前先要建立连接。UDP 是不需要连接即刻传输数据。
4.拥塞控制、流量控制、滑动窗口
TCP 有拥塞控制和流量控制机制保证数据的可靠传输。UDP 则没有即使网络非常拥堵了也不会影响 UDP 的发送速率。
5. 首部开销
TCP 首部长度较长会有一定的开销首部在没有使用「选项」字段时是 20个字节如果使用了「选项」字段则会变长的。UDP 首部只有 8 个字节并且是固定不变的开销较小。
6. 传输方式
TCP 是流式传输没有边界但保证顺序和可靠。UDP 是一个包一个包的发送是有边界的但可能会丢包和乱序。
7. 分片不同
TCP 的数据大小如果大于 MSS 大小则会在传输层进行分片目标主机收到后也同样在传输层组装 TCP 数据包如果中途丢失了一个分片只需要传输丢失的这个分片。UDP 的数据大小如果大于 MTU 大小则会在 IP 层进行分片目标主机收到后在 IP 层组装完数据接着再传给传输层。
TCP 和 UDP 应用场景
由于 TCP 是面向连接能保证数据的可靠性交付因此经常用于
FTP 文件传输HTTP / HTTPS
由于 UDP 面向无连接它可以随时发送数据再加上 UDP 本身的处理既简单又高效因此经常用于
包总量较少的通信如 DNS 、SNMP 等视频、音频等多媒体通信广播通信
基于TCP和UDP的协议各自有哪些
基于TCP的协议
HTTP/HTTPS超文本传输协议及其安全版本用于Web浏览器和服务器之间的通信。FTP文件传输协议用于文件的上传和下载。SMTP简单邮件传输协议用于电子邮件的发送。IMAP/POP3互联网邮件访问协议和邮局协议版本3用于电子邮件的接收。SSH安全外壳协议用于安全地访问远程计算机。Telnet用于远程登录到网络设备。SSL/TLS安全套接字层/传输层安全性用于在互联网上提供加密通信。DNS域名系统虽然DNS查询通常使用UDP但DNS的区域传输使用TCP
基于UDP的协议
DNS域名系统用于将域名解析为IP地址。DHCP动态主机配置协议用于自动分配IP地址给网络中的设备。TFTP简单文件传输协议用于文件传输尤其是在没有完整TCP/IP堆栈的情况下IGMP互联网组管理协议用于IP组播。
TCP如何保证传输的可靠性
1. 三次握手Three-Way Handshake
在建立连接时TCP使用三次握手来确保两个通信端点都准备好进行数据交换并且同步序列号这是可靠传输的基础。
2. 序列号和确认应答Sequence Numbers and Acknowledgments
序列号TCP将每个字节的数据都分配一个序列号确保数据按照正确的顺序传输。确认应答接收方收到数据后会发送一个确认应答ACK其中包含下一个期望收到的序列号。如果发送方没有收到确认应答它会重新发送数据。确保数据丢失
3. 重传机制Retransmission
如果发送方在预定的超时时间内没有收到确认应答它会假设数据包丢失或出错并重新发送数据。
4. 流量控制Flow Control
TCP使用滑动窗口机制进行流量控制以避免发送方发送数据过快导致接收方来不及处理。接收方通过调整窗口大小来告知发送方它能够接收的数据量。
5. 拥塞控制Congestion Control
TCP通过以下几种算法来避免网络拥塞
慢启动Slow Start连接开始时逐渐增加发送数据的速率。拥塞避免Congestion Avoidance当检测到网络拥塞时减少数据发送速率。快速重传Fast Retransmit在收到三个重复的ACK时不必等待超时立即重传丢失的数据包。快速恢复Fast Recovery在快速重传后调整窗口大小而不是从慢启动重新开始。 讲到HTTP了那你说一下HTTP和HTTPS的区别 HTTPS 协议需要向 CA证书权威机构申请数字证书来保证服务器的身份是可信的。 两者的默认端口不一样HTTP 默认端口号是 80HTTPS 默认端口号是 443。 HTTP 连接建立相对简单 TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后还需进行 SSL/TLS 的握手过程才可进入加密报文传输。 HTTP 连接建立相对简单 TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后还需进行 SSL/TLS 的握手过程才可进入加密报文传输。
你刚讲到HTTP基于SSL/TLS实现的安全加密具体如何实现的讲一下具体流程对称加密消息、非对称加密公钥
HTTP 由于是明文传输所谓的明文就是说客户端与服务端通信的信息都是肉眼可见的随意使用一个抓包工具都可以截获通信的内容。
所以安全上存在以下三个风险
窃听风险比如通信链路上可以获取通信内容用户号容易没。篡改风险比如强制植入垃圾广告视觉污染用户眼容易瞎。冒充风险比如冒充淘宝网站用户钱容易没。
HTTPS 在 HTTP 与 TCP 层之间加入了 TLS 协议来解决上述的风险。 TLS 协议是如何解决 HTTP 的风险的呢
信息加密 HTTP 交互信息是被加密的第三方就无法被窃取校验机制校验信息传输过程中是否有被第三方篡改过如果被篡改过则会有警告提示身份证书证明淘宝是真的淘宝网
传统的 TLS 握手基本都是使用 RSA 算法来实现密钥交换的在将 TLS 证书部署服务端时证书文件其实就是服务端的公钥会在 TLS 握手阶段传递给客户端而服务端的私钥则一直留在服务端一定要确保私钥不能被窃取。
TLS四次握手
第一次握手客户端首先会发一个「Client Hello」消息消息里面有客户端使用的 TLS 版本号、支持的密码套件列表以及生成的随机数这个随机数会被服务端保留它是生成对称加密密钥的材料之一。
第二次握手
当服务端收到客户端的「Client Hello」消息后会确认 TLS 版本号是否支持和从密码套件列表中选择一个密码套件以及生成随机数。接着返回Server Hello消息消息里面有服务器确认的 TLS 版本号也给出了随机数Server Random然后从客户端的密码套件列表选择了一个合适的密码套件。然后服务端为了证明自己的身份会发送Server Certificate给客户端这个消息里含有数字证书。随后服务端发了Server Hello Done消息目的是告诉客户端我已经把该给你的东西都给你了本次打招呼完毕。
第三次握手
客户端验证完证书后认为可信则继续往下走。
接着客户端就会生成一个新的随机数 (pre-master)用服务器的 RSA 公钥加密该随机数通过Client Key Exchange消息传给服务端。
服务端收到后用 RSA 私钥解密得到客户端发来的随机数 (pre-master)。
至此客户端和服务端双方都共享了三个随机数分别是 Client Random、Server Random、pre-master。
于是双方根据已经得到的三个随机数生成会话密钥Master Secret它是对称密钥用于对后续的 HTTP 请求/响应的数据加解密。
生成完「会话密钥」后然后客户端发一个Change Cipher Spec」告诉服务端开始使用加密方式发送消息。
然后客户端再发一个Encrypted Handshake MessageFinishd消息把之前所有发送的数据做个摘要再用会话密钥master secret加密一下让服务器做个验证验证加密通信「是否可用」和「之前握手信息是否有被中途篡改过」。
第四次握手
服务器也是同样的操作发「Change Cipher Spec」和「Encrypted Handshake Message」消息如果双方都验证加密和解密没问题那么握手正式完成。最后就用「会话密钥」加解密 HTTP 请求和响应了。
reentrantLock具体怎么去唤醒新线程的我希望听api应用层面的
1.通过条件变量Condition对象
lock.lock();condition.signal(); // 唤醒等待的线程
condition.await();// 让线程进入等待状态lock.unlock();
和synchronized一样condition也是只能在lock()方法和unlock()方法的中间使用 2.tryLock()尝试获取锁 tryLock()尝试获取锁如果锁不可用则立即返回false。如果锁可用则获取锁并返回true。 tryLock(long time, TimeUnit unit)尝试在指定时间内获取锁。如果锁在指定时间内不可用则返回false如果锁可用则获取锁并返回true。
你提到AQS那你知道AQS的设计模式是什么吗 模板方法模式AQS定义了同步器的骨架包括获取和释放锁的方法。这些方法是模板方法由子类来实现具体的逻辑。例如acquire和release方法是模板方法子类需要实现tryAcquire和tryRelease方法。 装饰器模式AQS提供了一种扩展同步器功能的方式允许通过添加额外的组件来增强其行为。例如ReentrantLock通过继承AQS并添加自己的逻辑来实现可重入的锁。 观察者模式AQS通过队列来管理等待获取同步状态的线程。当同步状态发生变化时它会通知等待的线程。这种模式使得AQS能够支持多种同步状态而不仅仅是简单的独占锁。 代理模式AQS通过代理类来提供同步器的操作接口这些代理类封装了具体的同步逻辑。例如ReentrantLock通过NonfairSync和FairSync代理类来实现非公平和公平锁。
装饰器模式和模板方法设计模式的区别是什么
装饰器模式和模板方法设计模式都是用于扩展和增强对象的行为但它们的应用场景和实现方式有所不同。
装饰器模式
目的在不修改对象结构的情况下动态地给对象添加额外的职责。实现方式通过创建一个装饰类该类持有被装饰对象的引用并在其方法中调用被装饰对象的方法。应用场景当需要在不改变现有对象结构的情况下为对象添加新的功能时。
模板方法设计模式
目的定义一个操作中的算法框架而将一些步骤延迟到子类中。实现方式通过定义一个抽象类或接口其中包含一个或多个抽象方法以及一个或多个具体方法模板方法。子类必须实现抽象方法而具体方法可以被重写或覆盖。应用场景当算法中有多个步骤但其中某些步骤可能需要子类定制时。
那你自己在项目中如何使用spring进行的aop呢 添加依赖在项目的pom.xml或build.gradle文件中添加Spring AOP的依赖。 定义切入点Pointcut使用Pointcut注解定义一个切入点它指定哪些方法将被拦截。 创建通知Advice定义一个通知类类上面加上aspect注解标明该类是一个切面类该类包含一个或多个通知方法这些方法将被应用到切入点指定的方法上。通知方法可以包括前置通知Before、后置通知After、环绕通知Around、异常通知AfterThrowing和最终通知After。 当方法执行到连接点时创建代理对象通过调用代理对象对应的方法织入通知。
什么情况下aop会失效请你结合自己的例子讲一下
1.没有被Spring容器管理的对象
2.同一个Bean内部方法调用如果一个Bean内部的方法直接调用同一个Bean内部的另一个方法AOP将无法拦截这个内部方法调用。因为AOP是基于代理的只有通过代理对象才能触发AOP拦截。
3.静态方法Spring的AOP只能拦截非静态方法。如果您尝试拦截静态方法AOP将无法生效。
4.final方法AOP无法拦截final方法。final方法是不可重写的因此AOP无法生成代理对象来拦截这些方法。
5.异步方法对于使用Spring的异步特性如Async注解的方法AOP拦截器可能无法正常工作。这是因为异步方法在运行时会创建新的线程或使用线程池AOP拦截器无法跟踪到这些新线程中的方法调用。
