第四天

kafka如何保证消息不丢失

Apache Kafka为了保证消息不丢失，采用了多种技术和配置来增强消息的持久化和可靠性。以下是一系列Kafka为保证消息不丢失而采取的措施：

1. 持久化存储：

   • Kafka将所有发布的消息持久化存储在磁盘上，而不是仅仅在内存中缓存。消息会被写入到日志文件中，这部分日志文件是落地存储的，即使服务器重启，消息也不会丢失。

2. 副本和ISR（In-Sync Replicas）机制：

   • Kafka的主题可以配置多个副本（partitions的副本），每个partition至少有一个Leader副本，其他副本是Follower副本。
   • Leader副本负责处理读写请求，Follower副本会不断从Leader同步数据，形成一个同步的ISR集合。
   • 在配置了合适的消息复制因子（replication.factor）后，只要 ISR 集合中的至少一个副本存活，就可以保证消息不丢失。

3. 异步复制和同步提交：

   • 默认情况下，Kafka producer在发送消息时可以选择异步或同步方式。如果想要确保消息不丢失，可以将acks参数设置为all或-1，这样只有当所有ISR副本都接收到消息后，Kafka才会向producer返回确认信息。

4. 幂等性（Idempotence）：

   • Kafka 0.11版本开始支持producer的幂等性，开启后，即使由于网络问题导致producer重试发送消息，Kafka也能确保每条消息只被存储一次，不会出现重复消息。

5. 日志刷盘策略：

   • Kafka可以配置日志刷盘策略，例如acks=all和flush.ms、linger.ms等参数组合，确保数据尽可能快地从缓存刷入磁盘。

6. 监控和运维：

   • 维护良好的Kafka集群健康状况，包括监控节点健康、确保磁盘空间足够、合理设置日志清理策略（log.retention.hours、log.segment.bytes等）等，也可以间接防止消息丢失。

sql优化场景:select id,name,balance from account where update_time > ‘2020-09-19’ limit 100000, 10该语句为什么查询慢? 有什么优化思路?

这条SQL语句可能查询较慢的原因及优化思路如下：

1. 全表扫描：
   如果update_time字段没有索引，那么数据库可能不得不进行全表扫描来找到符合条件的行，这在数据量很大的情况下会导致查询性能低下。

   优化思路：

   • 添加索引：为update_time字段创建索引，尤其是对于经常用于过滤查询的字段，创建索引可以显著加速查询速度。

2. LIMIT偏移量过大：
   SQL语句中的limit 100000, 10表示跳过前100000条记录并返回接下来的10条记录。这种带有大偏移量的LIMIT查询会导致数据库扫描到指定偏移量的行数，效率随着OFFSET值的增大而急剧下降。

   优化思路：

   • 分页优化：若可能，改用其他分页策略，如通过记录时间戳或唯一标识符进行分页，尤其是在大数据量分页时。
   • 游标：如果业务允许，使用游标（Cursor）代替一次性获取大量数据，特别是在Web应用中，使用无限滚动或者动态加载数据。
   • 索引覆盖查询：如果只是需要少量字段，尝试创建覆盖索引（Covering Index），这样在查询时，数据库可以直接从索引中获取所需数据，而无需回表查询。

3. 排序与索引不匹配：
   如果查询结果需要排序，并且update_time索引不是聚簇索引（对于InnoDB引擎，默认主键索引是聚簇索引），那么即使有索引，排序操作仍然可能影响性能。

   优化思路：

   • 有序索引扫描：如果业务允许，按照update_time排序并结合LIMIT，可以尝试让查询直接利用索引进行有序扫描，减少排序操作。

4. 数据分布不均：
   若update_time字段的数据分布不均匀，即使有索引，也可能导致查询不理想。

   优化思路：

   • 分析数据分布：针对update_time字段的数据分布进行分析，如果分布不均，可能需要重新评估查询策略或数据模型。

5. 查询优化器选择不当：
   数据库查询优化器可能选择了非最优的执行计划。

   优化思路：

   • 提示查询优化器：在某些数据库系统中，可以通过提示（hints）指导查询优化器选择正确的索引或执行计划。
   • 重建统计信息：确保数据库的统计信息是最新的，以便查询优化器做出最佳决策。