网站ip需要备案,请简述网络营销的特点,9420高清完整版视频在线观看1,网络营销员岗位的职责与要求面试指南 TMD#xff0c;一个后端为什么要了解那么多的知识#xff0c;真是服了。啥啥都得了解 MySQL
MySQL索引可能在以下几种情况下失效#xff1a;
不遵循最左匹配原则#xff1a;在联合索引中#xff0c;如果没有使用索引的最左前缀#xff0c;即查询条件中没有包含…面试指南 TMD一个后端为什么要了解那么多的知识真是服了。啥啥都得了解 MySQL
MySQL索引可能在以下几种情况下失效
不遵循最左匹配原则在联合索引中如果没有使用索引的最左前缀即查询条件中没有包含联合索引的第一列那么索引将会失效。使用了OR操作符即使在查询条件中使用了联合索引的全部列如果这些列之间是使用OR操作符连接的索引也可能会失效。数据类型转换如果在查询条件中对字段进行了隐式的类型转换比如将字符类型的字段与数字进行比较这可能导致索引失效。使用了函数或表达式在查询条件中对字段使用了函数或表达式如WHERE YEAR(date_column) 2023这样会使得索引失效。选择性低的索引如果索引的选择性很低即索引列的值重复率很高数据库优化器可能会选择全表扫描而不是使用索引。索引列上有函数或计算当索引列上有函数或计算时MySQL无法使用索引来查找行。全表扫描更快的情况当MySQL优化器估计出全表扫描比使用索引更快时系统会选择不使用索引。这通常发生在表中数据量较少或者查询返回大部分甚至所有行的情况下。
总的来说索引失效可能会导致查询性能下降因此在设计查询语句和索引时需要特别注意以上情况以确保索引能够发挥其应有的作用。
索引不适合哪些场景
数据量少的不适合加索引更新比较频繁的也不适合加索引区分度低的字段不适合加索引如性别
日常工作中你是怎么优化 SQL 的
在日常工作中使用SQL时优化是一个持续的过程旨在确保数据库查询的效率和性能。以下是一些常见的优化策略 使用EXPLAIN分析查询 使用EXPLAIN命令来分析SQL语句的执行计划从而理解MySQL如何执行查询哪些地方可能成为瓶颈。 正确地创建和使用索引 确保为经常用于搜索和排序的列创建索引。避免创建不必要的索引以减少插入、更新和删除操作的成本。使用复合索引来优化多列的查询条件。定期审查现有索引的有效性删除不再使用的索引。 编写高效的SQL语句 避免在WHERE子句中对字段进行函数转换或计算。减少使用OR操作符尤其是在索引列上因为它可能导致全表扫描。使用连接JOIN而不是子查询以便更有效地利用索引。仅选择需要的列而不是使用SELECT *。 优化数据模型 规范化表结构以避免数据冗余。在必要时使用反规范化来减少连接操作提高查询性能。 使用分区和分表 对于大型表考虑使用分区来提高查询性能。在数据量非常大的情况下可以考虑分表来分散负载。 调整数据库配置 根据服务器的硬件资源和应用需求调整MySQL的配置参数如缓冲池大小、连接数等。 监控和诊断 使用慢查询日志来识别低效的查询。使用性能监控工具来跟踪数据库的性能指标。 批量操作和事务控制 使用批量操作来减少数据库的I/O次数。合理使用事务确保数据的一致性同时避免长事务导致的锁竞争。 避免使用锁定的查询 尽量使用读已提交隔离级别避免不必要的行级锁。 定期维护 定期运行OPTIMIZE TABLE来整理表空间特别是对于经常修改的表。定期检查并修复表的错误。 学习和使用新的数据库特性 保持对MySQL新特性的了解如窗口函数、CTE公共表表达式等这些可以帮助编写更高效的查询。
通过上述方法可以显著提高SQL查询的性能。然而每个数据库和应用场景都是独特的因此可能需要根据具体情况调整优化策略。
OPTIMIZE TABLE 是什么
OPTIMIZE TABLE是MySQL中用于改善表性能的命令。它的主要作用是整理表的空间使用减少碎片提高数据访问效率。在表中进行大量插入、删除或更新操作后可能会产生空间碎片导致表的性能下降。使用OPTIMIZE TABLE命令可以重新组织表的数据释放未使用的空间让数据更紧凑地存储。
以下是使用OPTIMIZE TABLE的基本语法
OPTIMIZE TABLE table_name;其中table_name是要优化的表的名称。
OPTIMIZE TABLE命令执行的操作包括
整理表空间通过整理表的磁盘空间减少碎片使得数据行紧密排列从而提高I/O效率。更新统计信息更新表的统计信息帮助优化器选择更有效的执行计划。重建索引如果表的索引已经损坏或者因为碎片而效率低下OPTIMIZE TABLE可以重建索引提高索引的效率。减少文件碎片对于使用InnoDB存储引擎的表OPTIMIZE TABLE可以减少文件碎片提高空间利用率。
需要注意的是OPTIMIZE TABLE命令需要对表具有一定的锁定时间在此期间表无法进行写入操作。因此建议在系统负载较低的时段执行此命令以减少对应用的影响。
此外对于使用InnoDB存储引擎的表OPTIMIZE TABLE命令的效果可能不如预期因为InnoDB会自动进行页的合并和分裂来管理碎片。在这种情况下可以考虑使用ALTER TABLE命令来更改表的压缩模式以提高空间利用率和性能。
InnoDB 与 MyISAM 的区别
下面是InnoDB和MyISAM两种存储引擎在关键特性上的对比表格
特性InnoDBMyISAM事务支持支持完整的ACID事务不支持事务行级锁支持行级锁提高并发性能仅支持表级锁外键约束支持外键约束不支持外键数据文件和索引使用聚集索引数据文件存放在主键索引的叶子节点上使用非聚集索引数据文件和索引分开存储全文索引支持全文索引但需要额外配置和插件支持全文索引且无需额外配置数据恢复能力具有崩溃后的数据恢复能力遇到系统崩溃时数据恢复能力较弱缓存支持数据和索引的缓存只缓存索引表空间所有表共享一个表空间方便管理每个表单独存储为.frm、.MYD、.MYI文件适用场景适用于需要高并发、事务完整性保障的应用适用于读取密集型以及不要求事务的应用
注意这个表格中的信息可能随着MySQL版本的更新而有所变化。例如InnoDB在MySQL 5.6版本以后开始支持全文索引但通常认为MyISAM在全文索引方面更为成熟。此外MyISAM由于其设计简单在某些读密集的场景下可能有较好的性能表现但随着现代硬件的发展和多核处理器的普及InnoDB的性能优势愈发明显。
数据库索引的原理为什么要用 B树
数据库索引的原理是利用数据结构对数据进行排序以便快速查找。在数据库中B树是最常用的索引结构因为它具有以下优点
减少磁盘I/O操作B树的设计能够有效地减少访问节点的次数因为每个节点可以存储多个元素这意味着在查找过程中需要的磁盘I/O操作更少。每次磁盘访问都是昂贵的因此减少I/O操作次数对于性能至关重要。增加存储效率B树的非叶子节点不存储数据只存储索引而所有数据都保存在叶子节点中。这样的设计使得每个节点可以存储更多的索引从而使整个树的高度降低进一步减少了I/O操作的次数。提高查询稳定性由于所有数据都存在于叶子节点并且叶子节点之间通过链表连接这使得范围查询更加高效。在B树中进行范围查询时只需遍历叶子节点的链表即可而在二叉树中可能需要进行二次遍历。方便数据插入和删除B树的结构允许在不影响其他部分的情况下插入和删除数据这有助于保持树的平衡从而维持高效的查询性能。
为什么不用一般二叉树
不使用一般二叉树作为数据库索引的主要原因在于磁盘I/O操作和存储效率。让我们具体来看一下这些方面 磁盘I/O操作一般二叉树的节点只包含两个子节点的引用在二分查找的情况下以及数据这意味着每次查找都可能涉及到对磁盘的多次访问。因为数据库系统通常运行在磁盘上而不是内存中所以减少对磁盘的访问次数是提高性能的关键。 存储效率一般二叉树的节点存储了数据以及指向子节点的指针这导致存储密度较低。相比之下B树的非叶子节点仅存储键值没有实际的数据这使得每个节点可以拥有更多的键降低了树的高度提高了存储效率。 分支因子由于二叉树的结构限制每个节点只有两个分支。在B树中每个节点可以有更多的分支这增加了分支因子并减少了树的高度。 查询性能稳定性在二叉树中范围查询可能会导致性能不稳定因为需要遍历多个不连续的节点。而在B树中由于所有叶子节点通过指针连接成一个有序链表范围查询的性能更为稳定。 维护成本一般二叉树在插入和删除操作后可能需要重新平衡这个过程可能相对复杂。B树通过其设计来简化节点的分裂和合并过程使得维护成本更低。
因此虽然一般二叉树在理论的查找效率上可能与B树相当但在实际的数据库系统中B树提供了更好的性能特别是在处理大量数据时能够提供更高的数据访问效率和更低的存储成本。
为什么不是平衡二叉树
不使用平衡二叉树作为数据库索引的原因主要在于磁盘I/O操作的优化和范围查询的效率。B树相对于平衡二叉树有以下优势
减少磁盘I/O操作B树的高度较低通常在2-4层之间这意味着在查找记录时最多只需要2-4次磁盘I/O操作。而平衡二叉树的高度通常会更高因为它每个节点只存储一个数据项这会导致更多的磁盘访问从而降低了性能。提高范围查询效率B树的叶子节点通过指针连接成一个有序链表这使得进行范围查询时非常高效。例如在查找大于等于某个值的所有数据时一旦找到该值就可以通过叶子节点的指针连续获取所有相关数据而不需要像在平衡二叉树中那样回溯到父节点。增加存储效率B树的非叶子节点不存储实际数据只存储键值这样可以在每个节点中存储更多的键从而降低树的整体高度。平衡二叉树的每个节点存储了数据这限制了每个节点的键数导致树的高度增加。方便数据插入和删除B树的结构允许在不影响其他部分的情况下插入和删除数据这有助于保持树的平衡而平衡二叉树在插入和删除数据时需要更多的旋转操作来维持平衡这会增加维护成本。
综上所述虽然平衡二叉树提供了快速的查找性能但是B树在数据库索引中更为常用因为其结构更加适合磁盘I/O的特性并且在处理范围查询时更加高效。
为什么不是 B 树
数据库索引选择使用B树而不是B树主要是因为B树在磁盘I/O操作和存储效率方面具有更明显的优势。具体分析如下
磁盘I/O优化B树通过增加分支因子减少树的高度从而减少了查找数据时所需的磁盘I/O次数。由于磁盘读取是相对较慢的操作这种优化对于性能至关重要。提高查询效率B树的所有叶子节点都在同一层并且通过指针相连这为范围查询提供了便利。在B树中范围查询可能需要多次遍历不同层的节点效率较低。减少内存开销B树的非叶子节点不存储实际数据只存储键值这样可以减少内存的使用提高缓存的效率。方便维护B树的叶子节点包含所有键值而非叶子节点仅作为索引这使得节点的分裂和合并操作更加简单便于维护。
总的来说虽然B树和B树都是平衡多路查找树但是B树在数据库索引中的应用场景下因其结构特点提供了更好的性能优势。这也是为什么关系型数据库普遍采用B树作为索引结构的原因。
总结
综上所述B树通过其特有的结构优势能够提供更高效的数据访问路径尤其是在处理大量数据时这些优势使得B树成为数据库索引的首选结构。
事务的隔离级别有哪些
读未提交Read Uncommitted读已提交Read Committed可重复读Repeatable Read串行化Serializable
MySQL 的默认隔离级别是什么
Mysql 默认的事务隔离级别是可重复读(Repeatable Read)
MySQL中的Explain命令
MySQL中的Explain命令用于查看查询的执行计划。
Explain命令在MySQL中扮演着重要的角色它能够帮助开发者理解SQL语句的执行路径和成本从而对查询进行优化。使用Explain非常简单只需在SQL查询语句前加上EXPLAIN关键字即可。Explain的结果会以表格形式返回展示查询执行的细节信息。从MySQL 5.6版本开始Explain也支持非SELECT语句的解释。
Explain输出结果中包含多个字段每个字段代表不同的信息
id标识每个SELECT子句的唯一ID。select_type表示查询的类型例如简单查询、主查询、子查询等。table指出查询将访问哪张表。type显示了如何查找数据比如全表扫描、索引扫描或者范围扫描等。possible_keys可能应用在这张表上的索引。key实际使用的索引。如果为NULL则没有使用索引。key_len使用的索引的长度。ref哪个字段或常数与key一起被使用。rows预计需要读取的行数这个数值越小表明查询效率越高。filtered过滤后剩余的行数百分比这个值越大越好。extra额外的信息比如是否使用了临时表、是否进行了排序等。
总之通过分析这些字段的内容我们可以了解查询的性能瓶颈所在并据此采取相应的优化措施如添加或调整索引、改写查询逻辑等。
如果某个表有近千万数据CRUD 比较慢如何优化
如果某个表有近千万数据CRUD操作比较慢可以考虑以下几种优化方法 索引优化为经常用于查询条件的字段创建索引可以加快查询速度。但是要注意不要创建过多的索引因为索引也会占用存储空间和影响写入性能。 分库分表将数据分散到多个数据库或表中可以提高并发处理能力和扩展性。可以根据业务需求选择合适的分库分表策略如按照时间、地域、用户等进行分片。 读写分离将读操作和写操作分别分配给不同的数据库服务器可以提高系统的并发处理能力。可以通过主从复制或者使用专门的读写分离中间件实现。 缓存优化将热点数据缓存在内存中可以减少对数据库的访问次数提高系统性能。可以使用分布式缓存框架如Redis来实现。 SQL优化优化SQL语句避免使用子查询、临时表等可能导致性能下降的操作。可以使用Explain命令分析SQL执行计划找出性能瓶颈并进行优化。 硬件升级增加服务器的内存、CPU等硬件资源可以提高系统的处理能力。 数据库参数调优根据服务器的硬件配置和业务需求调整数据库的参数设置如缓冲区大小、连接数等以提高数据库的性能。 数据压缩对存储的数据进行压缩可以减少存储空间的占用提高I/O效率。 分区表将大表分成多个小表可以提高查询性能。可以根据业务需求选择合适的分区键如按照时间、地域等进行分区。 垂直拆分将一个大表拆分成多个小表每个小表只包含部分字段可以减少查询时需要扫描的数据量提高查询速度。
总之针对具体的业务场景和系统状况可以采用多种方法进行优化以达到提高CRUD性能的目的。
Mysql 主从复制原理
MySQL主从复制是一种数据同步机制允许数据从一个MySQL数据库服务器主节点复制到一个或多个其他服务器从节点。这种机制常用于实现数据的热备份、负载均衡和扩展。
以下是MySQL主从复制的基本原理
binlog二进制日志: 在主服务器上每当有数据变更发生时如INSERT、UPDATE或DELETE操作这些变更会被记录在binlog中。读取binlog: 从服务器连接到主服务器并请求主服务器发送新的binlog事件。这个过程可以通过IO线程来完成。relay log中继日志: 从服务器接收到来自主服务器的binlog事件后会将这些事件写入到自己的relay log中。应用binlog: 从服务器的另一个线程称为SQL线程会读取relay log中的事件并将它们依次应用到从服务器的数据库中从而保持与主服务器的数据一致性。
此外在实际应用中主从复制可能会存在一定的延时即从服务器的数据更新可能落后于主服务器。这种延时通常被称为同步延时。为了减少这种延时可以采用半同步复制的方式即在主服务器上等待至少一个从服务器确认接收到binlog事件后才认为该事件提交成功。 主从复制分了五个步骤进行 步骤一主库的更新事件(update、insert、delete)被写到 binlog 步骤二从库发起连接连接到主库。 步骤三此时主库创建一个 binlog dump thread把 binlog 的内容发送到从库。 步骤四从库启动之后创建一个 I/O 线程读取主库传过来的 binlog 内容并写入到 relay log 步骤五还会创建一个 SQL 线程从 relay log 里面读取内容从Exec_Master_Log_Pos 位置开始执行读取到的更新事件将更新内容写入到slave 的 db
Hash索引和B树索引的区别是什么
Hash索引和B树索引是数据库中常用的两种索引类型它们在查询效率和数据组织等方面存在一些区别。具体分析如下
查询效率对于等值查询Hash索引可以提供更快的查找速度因为它通过一次散列运算就能直接定位到数据的存储位置。而B树索引需要从根节点开始通过逐层遍历找到叶子节点这个过程涉及到多次磁盘I/O操作。数据组织B树索引的所有数据都存储在叶子节点并且叶子节点之间通过指针相连这使得范围查询非常高效。而Hash索引由于其数据组织方式不适合进行范围查询。冲突处理当多个不同的键值散列到同一个索引位置时会发生冲突。Hash索引通常使用链表来解决冲突这可能导致在最坏情况下查询效率降低。B树索引则没有这种冲突问题。插入和删除由于B树的结构特性插入和删除操作可以保持较高的效率尤其是在保持页面填充率的情况下。而Hash索引在处理大量插入和删除导致冲突增多时性能可能会受到影响。
总的来说Hash索引在等值查询方面具有明显的优势尤其是在查询效率上。然而B树索引在范围查询和有序性方面表现更好且更适合处理大量数据的插入和删除。在实际应用中选择哪种索引取决于具体的应用场景和需求。
count(1)、count(*) 与 count(列名) 的区别
在SQL中COUNT(1)、COUNT(*)和COUNT(列名)都是用来统计记录数量的函数但它们之间存在一些细微的区别
COUNT(1)这个函数会统计表中的所有记录数包括那些所有列都为NULL的记录。换句话说只要数据库中有这条记录无论记录的内容如何COUNT(1)都会将其计入总数。COUNT(*)这个函数与COUNT(1)的行为相同也会统计表中的所有记录数包括那些所有列都为NULL的记录。在大多数数据库系统中COUNT(*)和COUNT(1)的效率是相同的。COUNT(列名)这个函数会统计指定列中非NULL值的数量。如果某条记录的指定列值为NULL则这条记录不会被计入总数。这在统计某一特定列的有效数据时非常有用。
总的来说COUNT(1)和COUNT(*)在功能上是等价的它们都会计算表中的所有记录而COUNT(列名)则会忽略掉指定列中值为NULL的记录。在实际使用时选择哪种方式取决于你想要统计的内容。如果你想统计所有记录可以使用COUNT(1)或COUNT(*)如果你想统计特定列的非NULL值的数量那么应该使用COUNT(列名)。
mysql 中 int(20)和 char(20)以及 varchar(20)的区别
在MySQL中INT(20)、CHAR(20)和VARCHAR(20)是三种不同的数据类型它们用于存储不同类型的数据并且在存储方式和空间占用上也有所不同。 INT(20) 数据类型整数Integer。存储范围通常为-2147483648到2147483647取决于具体的数据库系统。显示长度括号中的数字表示显示宽度即在结果集中显示的字符数但这并不影响实际存储的空间大小或值的范围。空间占用通常占用4个字节的存储空间。 CHAR(20) 数据类型定长字符串Character。存储范围最多可以存储20个字符。显示长度括号中的数字表示字段可以存储的最大字符数。空间占用无论实际存储的数据长度如何都会占用20个字符的存储空间。如果实际数据长度不足20个字符剩余的空间会用空格填充。 VARCHAR(20) 数据类型变长字符串Variable Character。存储范围最多可以存储20个字符。显示长度括号中的数字表示字段可以存储的最大字符数。空间占用根据实际存储的数据长度动态分配存储空间最大不超过20个字符。不会像CHAR那样浪费空间。
需要注意的是这些数据类型的具体实现可能会因不同的数据库管理系统而有所差异。在实际使用时应根据数据的性质和应用场景选择合适的数据类型。 消息队列
什么是消息队列
你可以把消息队列理解为一个使用队列来通信的组件。它的本质就是个转发 器包含发消息、存消息、消费消息的过程。最简单的消息队列模型如下 我们通常说的消息队列简称 MQMessage Queue它其实就指消息 中间件当前业界比较流行的开源消息中间件包括 RabbitMQ、RocketMQ、Kafka。
消息队列有哪些使用场景/为什么使用消息队列
应用解耦流量削峰异步处理消息通讯远程调用
消息队列如何解决消息丢失问题
一个消息从生产者产生到被消费者消费主要经过这 3 个过程
因此如何保证 MQ 不丢失消息可以从这三个阶段阐述
生产者保证不丢消息存储端不丢消息消费者不丢消息
生产者保证不丢消息
生产端如何保证不丢消息呢确保生产的消息能到达存储端。 如果是 RocketMQ 消息中间件Producer 生产者提供了三种发送消息的方式分别是
同步发送异步发送单向发送
生产者要想发消息时保证消息不丢失可以
采用同步方式发送send 消息方法返回成功状态就表示消息正常到达了存储端Broker。如果 send 消息异常或者返回非成功状态可以重试。可以使用事务消息RocketMQ 的事务消息机制就是为了保证零丢失来设计的
存储端不丢消息
如何保证存储端的消息不丢失呢 确保消息持久化到磁盘。大家很容易想到就 是刷盘机制。 刷盘机制分同步刷盘和异步刷盘
生产者消息发过来时只有持久化到磁盘RocketMQ 的存储端 Broker 才返回一 个成功的 ACK 响应这就是同步刷盘。它保证消息不丢失但是影响了性能。异步刷盘的话只要消息写入 PageCache 缓存就返回一个成功的 ACK 响应。 这样提高了 MQ 的性能但是如果这时候机器断电了就会丢失消息。
Broker 一般是集群部署的有 master 主节点和 slave 从节点。消息到Broker 存储端只有主节点和从节点都写入成功才反馈成功的 ack 给生产者。这就是同步复制它保证了消息不丢失但是降低了系统的吞吐量。与之对应的就是异步复制只要消息写入主节点成功就返回成功的 ack它速度快但是会有性能问题。
消费阶段不丢消息
消费者执行完业务逻辑再反馈会 Broker 说消费成功这样才可以保证消费 阶段不丢消息。
消息队列有可能发生重复消费如何避免如何做到幂等
消息队列是可能发生重复消费的。
生产端为了保证消息的可靠性它可能往 MQ 服务器重复发送消息直到拿到成功 的 ACK。再然后就是消费端消费端消费消息一般是这个流程拉取消息、业务逻辑处理、 提交消费位移。假设业务逻辑处理完事务提交了但是需要更新消费位移时消 费者挂了这时候另一个消费者就会拉到重复消息了。
如何幂等处理重复消息呢
幂等处理重复消息简单来说就是搞个本地表带唯一业务标记的利用主 键或者唯一性索引每次处理业务先校验一下就好啦。又或者用 redis 缓存 下业务标记每次看下是否处理过了。
如何处理消息队列的消息积压问题
消息积压是因为生产者的生产速度大于消费者的消费速度。遇到消息积压问 题时我们需要先排查是不是有 bug 产生了。 如果不是 bug我们可以优化一下消费的逻辑比如之前是一条一条消息消费 处理的话我们可以确认是不是可以优为批量处理消息。 如果还是慢我们可 以考虑水平扩容增加 Topic 的队列数和消费组机器的数量提升整体消费 能力
如果是 bug 导致几百万消息持续积压几小时。有如何处理呢 需要解决 bug临时紧急扩容大概思路如下
先修复 consumer 消费者的问题以确保其恢复消费速度然后将现有consumer 都停掉。新建一个 topicpartition 是原来的 10 倍临时建立好原先 10 倍的 queue数量。然后写一个临时的分发数据的 consumer 程序这个程序部署上去消费积压的数据消费之后不做耗时的处理直接均匀轮询写入临时建立好的 10 倍数量的 queue。接着临时征用 10 倍的机器来部署 consumer每一批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍以正常的 10 倍速度来消费数据。等快速消费完积压数据之后得恢复原先部署的架构重新用原先的consumer 机器来消费消息。
消息队列技术选型Kafka 还是 RocketMQ还是RabbitMQ
先可以对比下它们优缺点
RabbitMQ 是开源的比较稳定的支持活跃度也高但是不是 Java 语言开发的。很多公司用 RocketMQ是阿里出品的。如果是大数据领域的实时计算、日志采集等场景用 Kafka 是业内标准的。
如何保证数据一致性事务消息如何实现
一条普通的 MQ 消息从产生到被消费大概流程如下
生产者产生消息发送带 MQ 服务器MQ 收到消息后将消息持久化到存储系统。MQ 服务器返回 ACK到生产者。MQ 服务器把消息 push 给消费者消费者消费完消息响应 ACKMQ 服务器收到 ACK认为消息消费成功即在存储中删除消息。
我们举个下订单的例子吧。订单系统创建完订单后再发送消息给下游系统。如果订单创建成功然后消息没有成功发送出去下游系统就无法感知这个事情出导致数据不一致。 如何保证数据一致性呢可以使用事务消息。一起来看下事务消息是如何实现的吧。
生产者产生消息发送一条半事务消息到 MQ 服务器MQ 收到消息后将消息持久化到存储系统这条消息的状态是待发送状态。MQ 服务器返回 ACK 确认到生产者此时 MQ 不会触发消息推送事件生产者执行本地事务如果本地事务执行成功即 commit 执行结果到 MQ 服务器如果执行失败发 送 rollback。如果是正常的 commitMQ 服务器更新消息状态为可发送如果是 rollback即 删除消息。如果消息状态更新为可发送则 MQ 服务器会 push 消息给消费者。消费者消费完 就回 ACK。如果 MQ 服务器长时间没有收到生产者的 commit 或者 rollback它会反查生产 者然后根据查询到的结果执行最终状态。
网络 对称加密与非对称加密有什么区别
对称加密指加密和解密使用同一密钥优点是运算速度较快缺点是如何安 全将密钥传输给另一方。常见的对称加密算法有DES、AES 等。
非对称加密指的是加密和解密使用不同的密钥即公钥和私钥。公钥与私 钥是成对存在的如果用公钥对数据进行加密只有对应的私钥才能解密。常 见的非对称加密算法有 RSA。
DNS 的解析过程
DNS英文全称是 domain name system域名解析系统是 Internet上作为域名和 IP 相互映射的一个分布式数据库。它的作用很明确就是可以根据域名查出对应的 IP 地址。在浏览器缓存、本地 DNS 服务器、根域名服务器都是怎么查找的大家回答的时候都可以说下哈。 DNS 的解析过程如下图
forward 和 redirect 的区别
直接转发方式Forward 客户端和浏览器只发出一次请求 Servlet、HTML、JSP 或其它信息资源由第二个信息资源响应该请求在请 求对象 request 中保存的对象对于每个信息资源是共享的。间接转发方式Redirect 实际是两次 HTTP 请求服务器端在响应第一次 请求的时候让浏览器再向另外一个 URL 发出请求从而达到转发的目的。
Redirect 的工作原理 forward 的工作原理
聊聊 SQL 注入
SQL 注入是一种代码注入技术一般被应用于攻击 web 应用程序。它通过在web 应用接口传入一些特殊参数字符来欺骗应用服务器执行恶意的 SQL命令以达到非法获取系统信息的目的。它目前是黑客对数据库进行攻击的最常用手段之一
请详细介绍一下 TCP 的三次握手机制 第一次握手(SYN1, seqx)发送完毕后客户端就进入 SYN_SEND 状态第二次握手(SYN1, ACK1, seqy, ACKnumx1) 发送完毕后服务器 端就进入 SYN_RCV 状态。第三次握手(ACK1ACKnumy1)发送完毕后客户端进入 ESTABLISHED 状态当服务器端接收到这个包时也进入 ESTABLISHED 状态。
TCP 握手为什么是三次为什么不能是两次不能是四次
思路: TCP 握手为什么不能是两次为什么不能是四次呢为了方便理解我 们以男孩子和女孩子谈恋爱为例子两个人能走到一起最重要的事情就是相 爱就是我爱你并且我知道你也爱我接下来我们以此来模拟三次握手的 过程
为什么握手不能是两次呢
如果只有两次握手女孩子可能就不知道她的那句我也爱你男孩子是否收 到恋爱关系就不能愉快展开。
为什么握手不能是四次呢
因为握手不能是四次呢因为三次已经够了三次已经能让双方都知道你爱 我我也爱你。而四次就多余了。
TCP 四次挥手过程? TCP 四次挥手过程
第一次挥手(FIN1sequ)发送完毕后客户端进入 FIN_WAIT_1 状态。第二次挥手(ACK1acku1,seq v)发送完毕后服务器端进入CLOSE_WAIT 状态客户端接收到这个确认包之后进入 FIN_WAIT_2 状态。第三次挥手(FIN1ACK1,seqw,acku1)发送完毕后服务器端进入LAST_ACK 状态等待来自客户端的最后一个 ACK。第四次挥手(ACK1sequ1,ackw1)客户端接收到来自服务器端的关闭请求发送一个确认包并进入 TIME_WAIT 状态等待了某个固定时间两个最大段生命周期2MSL2 Maximum Segment Lifetime之后没有收到服务器端的 ACK 认为服务器端已经正常关闭连接于是自己也关闭连接进入 CLOSED 状态。服务器端接收到这个确认包之后关闭连接进入 CLOSED 状态。
TCP 挥手为什么需要四次呢
思路 TCP 挥手为什么需要四次呢为了方便大家理解再举个生活的例子吧。 小明和小红打电话聊天通话差不多要结束时小红说“我没啥要说的了”。小明回答“我知道了”。但是小明可能还有要说的话小红不能要求小明跟着她自己的节奏结束通话于是小明可能又叽叽歪歪说了一通最后小明说“我说完了”小红回答“我知道了”这样通话才算结束。
TCP 四次挥手过程中为什么需要等待 2MSL,才进入CLOSED 关闭状态 2MSLtwo Maximum Segment Lifetime即两个最大段生命周期。 假设主动发起挥手的是客户端那么需要 2MSL 的原因是
为了保证客户端发送的最后一个 ACK 报文段能够到达服务端。 这个 ACK 报 文段有可能丢失因而使处在 LAST-ACK 状态的服务端就收不到对已发送的 FIN ACK 报文段的确认。服务端会超时重传这个 FINACK 报文段而客 户端就能在 2MSL 时间内超时 1MSL 传输收到这个重传的 FINACK 报文段。接着客户端重传一次确认重新启动 2MSL 计时器。最后客户端和 服务器都正常进入到 CLOSED 状态。防止已失效的连接请求报文段出现在本连接中。客户端在发送完最后一个 ACK 报文段后再经过时间 2MSL就可以使本连接持续的时间内所产生的所 有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接 请求报文段。
说说 TCP 是如何确保可靠性的呢
首先TCP 的连接是基于三次握手而断开则是基于四次挥手。确保连接和断开的 可靠性。其次TCP 的可靠性还体现在有状态;TCP 会记录哪些数据发送了哪些数据被接收了哪些没有被接受并且保证数据包按序到达保证数据传输不出差错。再次TCP 的可靠性还体现在可控制。它有数据包校验、ACK 应答、超时重传(发送方)、失序数据重传接收方、丢弃重复数据、流量控制滑动窗口和拥塞控制等机制。
请简述 TCP 和 UDP 的区别
TCP 面向连接如打电话需要先拨号UDP 面向无连接即发送数据前不需要建立连接。TCP 提供可靠的服务UDP 无法保证。TCP 面向字节流而 UDP 面向报文。TCP 数据传输慢UDP 数据传输快TCP 是点对点连接的UDP 可以一对一一对多多对多都可以。TCP 适用于邮件、网页等UDP 适用于语音广播等。
Java
StringStringbufferStringBuilder 的区别
String String 类是一个不可变的类一旦创建就不可以修改。String 是 final 类不能被继承String 实现了 equals()方法和 hashCode()方法 StringBuffer 继承自 AbstractStringBuilder是可变类。StringBuffer 是线程安全的可以通过 append 方法动态构造数据。 StringBuilder 继承自 AbstractStringBuilder是可变类。StringBuilder 是非线性安全的。执行效率比 StringBuffer 高。
Java中的几种基本数据类型是什么各自占用多少字节呢
byte占用1个字节8位取值范围从-128到127。short占用2个字节16位取值范围从-32768到32767。int占用4个字节32位取值范围从-2147483648到2147483647。long占用8个字节64位取值范围从-9223372036854775808到9223372036854775807。float占用4个字节32位取值范围从-3.4e38到3.4e38。double占用8个字节64位取值范围从-1.7e308到1.7e308。char占用2个字节16位用于表示Unicode字符取值范围从’\u0000’到’\uffff’。boolean虽然理论上占用1位1/8字节在实际应用中通常按1个字节处理
