重庆网站推广产品,有哪些做图纸的网站,手机怎么浏览国外网站,适合个人做的跨境电商平台我们都知道互联网数据有个特性#xff0c;大部分场景都是 读多写少#xff0c;比如#xff1a;微博、微信、淘宝电商#xff0c;按照 二八原则#xff0c;读流量占比甚至能达到 90%结合这个特性#xff0c;我们对底层的数据库架构也会做相应调整。采用 读写分离处理过程大部分场景都是 读多写少比如微博、微信、淘宝电商按照 二八原则读流量占比甚至能达到 90%结合这个特性我们对底层的数据库架构也会做相应调整。采用 读写分离处理过程客户端会集成 SDK每次执行 SQL 时会判断是 写 或 读 操作如果是 写 SQL请求会发到 主库主数据库执行SQL事务提交后会生成 binlog 并同步给 从库从库 通过 SQL 线程回放 binlog 并在从库表中生成相应数据如果是 读 SQL请求会通过 负载均衡 策略挑选一个 从库 处理用户请求看似非常合理细想却不是那么回事主库 与 从库 是采用异步复制数据如果这两者之间数据还没有同步怎么办主库刚写完数据从库还没来得及拉取最新数据读 请求就来了给用户的感觉数据丢了针对这个问题今天我们就来探讨下有什么解决方案一、强制走主库针对不用的业务诉求区别性对待场景一如果是对数据的 实时性 要求不是很高比如大V有千万粉丝发布一条微博粉丝晚几秒钟收到这条信息并不会有特别大的影响。这时可以走 从库。场景二如果对数据的 实时性 要求非常高比如金融类业务。我们可以在客户端代码标记下让查询强制走主库。二、从库延迟查询由于主从库之间数据同步需要一定的时间间隔那么有一种策略是延迟从从库查询数据。比如select sleep(1)
select * from order where order_id11111;在正式的业务查询时先执行一个sleep 语句给从库预留一定的数据同步缓冲期。因为是采用一刀切当面对高并发业务场景时性能会下降的非常厉害一般不推荐这个方案。三、判断主从是否延迟决定选主库还是从库方案一在从库 执行 命令 show slave status查看 seconds_behind_master 的值单位为秒如果为 0表示主备库之间无延迟方案二比较主从库的文件点位还是执行 show slave status响应结果里有截个关键参数Master_Log_File 读到的主库最新文件Read_Master_Log_Pos 读到的主库最新文件的坐标位置Relay_Master_Log_File 从库执行到的最新文件Exec_Master_Log_Pos 从库执行到的最新文件的坐标位置两两比较上面的参数是否相等方案三比较 GTID 集合Auto_Position1 主从之间使用 GTID 协议Retrieved_Gtid_Set 从库收到的所有binlog日志的 GTID 集合Executed_Gtid_Set 从库已经执行完成的 GTID 集合比较 Retrieved_Gtid_Set 和 Executed_Gtid_Set 的值是否相等在执行业务SQL操作时先判断从库是否已经同步最新数据。从而决定是操作主库还是操作从库。缺点无论采用上面哪一种方案如果主库的写操作频繁不断那么从库的值永远跟不上主库的值那么读流量永远是打在了主库上。针对这个问题有什么解决方案这个问题跟 MQ消息队列 既要求高吞吐量又要保证顺序是一样的从全局来看确实无解但是缩小范围就容易多了我们可以保证一个分区内的消息有序。回到 主从库 之间的数据同步问题从库查询哪条记录我们只要保证之前对应的写binglog已经同步完数据即可可以不用管主从库的所有的事务binlog 是否同步。问题是不是一下简单多了四、从库节点判断主库位点在从库执行下面命令返回是一个正整数 M表示从库从参数节点开始执行了多少个事务select master_pos_wait(file, pos[, timeout]);file 和 pos 表示主库上的文件名和位置timeout 可选 表示这个函数最多等待 N 秒缺点master_pos_wait 返回结果无法与具体操作的数据行做关联所以每次接收读请求时从库还是无法确认是否已经同步数据方案实用性不高。五、比较 GTID执行下面查询命令阻塞等待直到从库执行的事务中包含 gtid_set返回 0超时返回 1select wait_for_executed_gtid_set(gtid_set, 1);MySQL 5.7.6 版本开始允许在执行完更新类事务后把这个事务的 GTID 返回给客户端。具体操作将参数session_track_gtids 设置为OWN_GTID调用 API 接口mysql_session_track_get_first 返回结果解析出 GTID处理流程发起 写 SQL 操作在主库成功执行后返回这个事务的 GTID发起 读 SQL 操作时先在从库执行 select wait_for_executed_gtid_set (gtid_set, 1)如果返回 0表示已经从库已经同步了数据可以在从库执行 查询 操作否则在主库执行 查询 操作缺点跟上面的 master_pos_wait 类似如果 写操作 与 读操作 没有上下文关联那么 GTID 无法传递 。方案实用性不高。六、引入缓存中间件高并发系统缓存作为性能优化利器应用广泛。我们可以考虑引入缓存作为缓冲介质处理过程客户端 写 SQL 操作主库同步将缓存中的数据删除当客户端读数据时优先从缓存加载如果 缓存中没有会强制查询主库预热数据缺点K-V 存储适用一些简单的查询条件场景。如果复杂的查询还是要查询从库。七、数据分片参考 Redis Cluster 模式 集群网络拓扑通常是 3主 3从主节点既负责写也负责读。通过水平分片支持数据的横向扩展。由于每个节点都是独立的服务器可以提高整体集群的吞吐量。转换到数据库方面常见的解决方式是分库分表每次读写都是操作主库的一个分表从库只用来做数据备份。当主库发生故障时主从切换保证集群的高可用性。往期推荐Spring官方推荐的Transactional还能导致生产事故Objects.equals有坑为什么创建线程池一定要用ThreadPoolExecutor
