sqlserver 读写分离 怎么处理新增后立马刷新

[qiushangju]

sqlserver读写分离后,读库和主库会有一定时间的延迟,当业务逻辑是增加记录后马上刷新列表之类的逻辑时,怎么处理??

[吉普赛的歌]

引用 楼主 qiushangju 的回复:

sqlserver读写分离后,读库和主库会有一定时间的延迟,当业务逻辑是增加记录后马上刷新列表之类的逻辑时,怎么处理??

alwayson ? 其实这个延迟一般情况下不会太大， 一般几十ms 到 几百 ms. 也可以在增加记录之后 Thread.Sleep(1000) 休眠一秒， 然后再刷新列表， 问题不大的。 特别重要的（关系到钱）的业务， 就只能直接读主库了。 没必要太计较这个东西， 对于分隔报表类的业务 ( OLAP ) 更适合， OLTP 只能用于不太主要的方面（比如登录请求辅助副本就没问题）。

[圣殿骑士18]

引用 11 楼 yenange 的回复:

引用 10 楼 qq_30465445 的回复:

[quote=引用 9 楼 sp1234 的回复:] 架构知识方面的问题，要抄什么代码？

对 就是 这方面相关的书 之类的 什么的东西 怪我没说清楚， 刚工作一年，积累不够，别介意啊

不明白你为什么就不看我的#1。 这里是 C# 论坛， 很多人都没用过 alwayson。 你觉得能说出多少真实东西出来？ 我在#1 都是经验之谈， 实战过的了。[/quote] 呵，楼主的思路已经被p哥带偏了。 楼主你一年经验，就不要按1#的方法去研究，p哥的思路估计你还体会不了，要弄巧成拙的。

[圣殿骑士18]

就不要按1#的方法去研究 =》 就按1#的方法去研究

[以专业开发人员为伍]

要是不容许有不一致性，那你就别分离了。

[exception92]

业务逻辑是增加记录后马上刷新列表之类的逻辑时 -》新增成功之后将数据添加到本地集合（BindingList/ObservableCollection）这样能将结果通知到UI列表显示，而不是再从新读取全部数据。

[以专业开发人员为伍]

实际上读写分离相当程度上是增加了问题、增加了困难，而不是减少了问题。真正应该首先做到的是，尽量在逻辑中避免使用事务概念、甚至避免使用关系数据库，尽量将面向数据库增删改查的程序改为面向（几百万）微服务的并发程序。然而很多人没有这方面的理解，认为把数据库分库分表读写分离这类“优化”最简单，所以一味地浪费精力在看似最简单实则已经逐步脱离时代的优化概念上。

[以专业开发人员为伍]

分离数据库不是什么好主意，甚至可以说是“坑爹”的。现在的大规模高性能的程序，实际上是去掉增删改查数据库层概念，而是面向全局一致性分布式数据缓存层来编程。 高性能系统是去低级的数据库层，而是使用中间件层，也就是在后台业务逻辑处理中也要至少三层设计。

[以专业开发人员为伍]

你会发现只是在数据库概念上用点30年前的优化概念时，纠结了2年，最终你还是不能跟上这个分布式大数据时代的编程要求。

[娃都会打酱油了]

具备维护功能的代码本身应该是读写在写的数据库上，而不是写在写数据库，而读在读数据库

[sprints_昊天]

引用 5 楼 sp1234 的回复:

分离数据库不是什么好主意，甚至可以说是“坑爹”的。现在的大规模高性能的程序，实际上是去掉增删改查数据库层概念，而是面向全局一致性分布式数据缓存层来编程。 高性能系统是去低级的数据库层，而是使用中间件层，也就是在后台业务逻辑处理中也要至少三层设计。

大佬 有没有相关的文档说明或者其他的说明什么的

[以专业开发人员为伍]

架构知识方面的问题，要抄什么代码？

[sprints_昊天]

引用 9 楼 sp1234 的回复:

架构知识方面的问题，要抄什么代码？

对 就是 这方面相关的书 之类的 什么的东西 怪我没说清楚， 刚工作一年，积累不够，别介意啊

[以专业开发人员为伍]

你会发现，其实让你忽略这种数据不一致性并不会“解决”任何问题，顶多是说一些“用ssd硬盘、用更快速的log来更新 slave库”之类的话。 你会发现，各种文章中真正有点用处的是那些使用 redis 等等的中间全局缓存层的架构设计。然后如果说这种东西“跑偏了”，我只能说可能是离大公司的架构还很远，连中间全局cache层都不设计，这种“读写分离”纯粹是小办公室OA程序中的读写分离了。凡是大的（特别是起码2台以上服务器的）业务处理系统都要有中间缓存层，而数据就是由这个中间层去写到Master数据库中，所谓地读取Slave数据也是首先从中间层读取数据，并不是纠结于什么Master/Slave数据库。

[以专业开发人员为伍]

你看任何一个大公司的系统设计，全都是这样的，全都有中间层的。所以你问“有没有相关的文档说明或者其他的说明什么的”，我觉得你需要先学习大公司的机构设计，然后你先提出你的设计问题来。如果你想100步登上泰山，这个就太脱离现实了，你根据大公司的值得进行分离的大型架构（而不是小OA程序的架构）来提出的问题、才可能得到相应的解答。

[以专业开发人员为伍]

先学习大公司的机构设计 --> 先学习大公司的架构设计 比如说你不从其它地方（例如 InfoQ）学习一系列大公司服务架构演进过程，而是只是问“读写分离”这个概念本身，那么这不是我要回答的重点问题。如果只是一个概念，是不能随便用的。一个架构一定是放到环境中，一系列实践最终筛选出来的架构。 不是说随便弄个“读写分离”的 master/slave 数据库订阅就高级了，而是要切实解决数据一致性问题。特别是当服务器有2台以上的时候（实际上小公司为了稳定性，也起码有2台服务器），一定要保持数据对象在全局的一致性，不是随便容忍不一致。所以此时技术往往就体现在如何保持数据一致性上，而不是忽略一致性。

[sp1234_maJia]

说白了，不外乎通常会有3种说法： 1. 任性地让不一致性由用户去“理解”。 2. 锁死数据库复制，等复制完成之后才算是向 Master 写数据成功。 3. 基于中间存储管理层来设计开发，而放弃所谓的“增删改查关系数据库”的设计思路。 前两种都不是现代的大系统的技术。

[sprints_昊天]

引用 13 楼 daixf_csdn 的回复:

就不要按1#的方法去研究 =》 就按1#的方法去研究

话说 我不是楼主啊,我就是逛论坛,发现了有趣的东西进来看看诶

[qiushangju]

引用 17 楼 sp1234_maJia 的回复:

说白了，不外乎通常会有3种说法：

1. 任性地让不一致性由用户去“理解”。
2. 锁死数据库复制，等复制完成之后才算是向 Master 写数据成功。
3. 基于中间存储管理层来设计开发，而放弃所谓的“增删改查关系数据库”的设计思路。

前两种都不是现代的大系统的技术。

嗯 你是对的

[qiushangju]

引用 18 楼 qq_30465445 的回复:

引用 13 楼 daixf_csdn 的回复:

就不要按1#的方法去研究 =》 就按1#的方法去研究

话说 我不是楼主啊,我就是逛论坛,发现了有趣的东西进来看看诶

忘了结贴了 话说 我才是楼主啊

[qiushangju]

引用 1 楼 yenange 的回复:

[quote=引用 楼主 qiushangju 的回复:]
sqlserver读写分离后,读库和主库会有一定时间的延迟,当业务逻辑是增加记录后马上刷新列表之类的逻辑时,怎么处理??

alwayson ?
其实这个延迟一般情况下不会太大， 一般几十ms 到 几百 ms. 也可以在增加记录之后 Thread.Sleep(1000) 休眠一秒， 然后再刷新列表， 问题不大的。
特别重要的（关系到钱）的业务， 就只能直接读主库了。
没必要太计较这个东西， 对于分隔报表类的业务 ( OLAP ) 更适合， OLTP 只能用于不太主要的方面（比如登录请求辅助副本就没问题）。[/quote]

这个我是知道的呀