一、前言 我们都知道，ASP.NET Core作为最新的框架，在MVC5和ASP.NET WebForm的基础上做了大量的重构。如果我们想使用以前版本中的HttpContext.Current的话，目前是不可用的，因为ASP.NET Core中是并没有这个API的。 当然我们也可以通过在Controller中访问HttpContext，但是某些情况下，这样使用起来还是不如HttpContext.Current方便。 二、IHttpContextAccessor 利用ASP.NET Core的依赖注入容器系统，通过请求获取IHttpContextAccessor接口，我们拥有模拟使用HttpContext.Current这样API的可能性。但是因为IHttpContextAccessor接口默认不是由依赖注入进行实例管理的。我们先要将它注册到ServiceCollection中：
|
1 2 3 4 5 6 |
public void ConfigureServices(IServiceCollection services) { services.TryAddSingleton<IHttpContextAccessor, HttpContextAccessor>(); // Other code... } |
来模拟一个HttpContext.Current吧：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
public static class HttpContext { public static IServiceProvider ServiceProvider; public static Microsoft.AspNetCore.Http.HttpContext Current { get { object factory = ServiceProvider.GetService(typeof(Microsoft.AspNetCore.Http.IHttpContextAccessor)); Microsoft.AspNetCore.Http.HttpContext context = ((Microsoft.AspNetCore.Http.HttpContextAccessor)factory).HttpContext; return context; } } } |
其实说到HttpContext.Current就不得不提到多线程问题，在以前的ASP.NET版本中，如果遇到多线程环境很有可能HttpContext.Current为空的情况。说到这个问题以前就是有解决方案的，那就是CallContext; CallContext 是类似于方法调用的线程本地存储区的专用集合对象，并提供对每个逻辑执行线程都唯一的数据槽。数据槽不在其他逻辑线程上的调用上下文之间共享。当 CallContext 沿执行代码路径往返传播并且由该路径中的各个对象检查时，可将对象添加到其中。 当使用ASP.NET的时候，虽然线城池里的线程是复用的，但是CallContext并不在一个线程的多次使用中共享。因为CallContext是针对逻辑线程的TLS，线程池中被复用的线程是操作系统中的内核对象而不是托管对象。就像数据库连接池中保存的是非托管资源而不是托管资源。因此，先后执行的两个托管线程可能在底层复用了一个物理线程（内核对象），但并不能共享同一组CallContext数据槽。就像先后new的两个SqlConnection对象可能在底层使用了同一个物理连接，但是托管对象的属性已经被重置。 与此对照的是ThreadStaticAttribute，标记上这个特性的静态字段是往物理线程的TLS中保存数据（根据MSDN的描述猜的。具体没试过），因此如果两个托管线程对象内部使用的是同一个物理线程，则这个字段会复用（在两个线程通过这一字段访问同一个数据槽）。 在.NET Core中，也有新的API选择，AsyncLocal<T>。 三、HttpContextAccessor 我们来看看ASP.NET Core中的IHttpContextAccessor接口实现吧：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
public class HttpContextAccessor : IHttpContextAccessor { #if NET451 private static readonly string LogicalDataKey = "__HttpContext_Current__" + AppDomain.CurrentDomain.Id; public HttpContext HttpContext { get { var handle = CallContext.LogicalGetData(LogicalDataKey) as ObjectHandle; return handle?.Unwrap() as HttpContext; } set { CallContext.LogicalSetData(LogicalDataKey, new ObjectHandle(value)); } } #elif NETSTANDARD1_3 private AsyncLocal<HttpContext> _httpContextCurrent = new AsyncLocal<HttpContext>(); public HttpContext HttpContext { get { return _httpContextCurrent.Value; } set { _httpContextCurrent.Value = value; } } #endif } |
最后我只能说在ASP.NET Core中是万物皆DI啊，其实Core中的实现早就为我们想好了这些功能，只是改变了使用方式。 GitHub：https://github.com/maxzhang1985/YOYOFx 如果觉还可以请Star下， 欢迎一起交流。 .NET Core 开源学习群： 214741894 from:https://www.cnblogs.com/maxzhang1985/p/6186455.html
View Details在我们用来获取客户端IP地址的传统ASP.NET中Request.UserHostAddress。但是这不适用于ASP.NET Core 2.0。我们需要一种不同的方式来检索HTTP请求信息。 1.在你的MVC控制器中定义一个变量
|
1 |
private IHttpContextAccessor _accessor; |
2. DI进入控制器的构造函数 public SomeController(IHttpContextAccessor accessor) { _accessor = accessor; } 3.回传IP地址
|
1 |
_accessor.HttpContext.Connection.RemoteIpAddress.ToString() |
这RemoteIpAddress是在类型IPAddress，而不是string。它包含了IPv4，IPv6等信息，它不像经典的ASP.NET，对我们来说更有用。 from:https://blog.csdn.net/yzj_xiaoyue/article/details/79200714
View DetailsAppContext.BaseDirectory 获取项目的根目录 from:https://www.cnblogs.com/zxs-onestar/p/7147265.html
View Details使用我这个方式的前提是在mvc中，确认你安装了：Microsoft.AspNetCore.Mvc. 然后在继承了Controller的类型中使用我所说的方法。 直接使用即可，我是封装了方法供我自己使用，代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
public abstract class ControllerBase : Controller { /// <summary> /// 设置本地cookie /// </summary> /// <param name="key">键</param> /// <param name="value">值</param> /// <param name="minutes">过期时长，单位：分钟</param> protected void SetCookies(string key, string value, int minutes = 30) { HttpContext.Response.Cookies.Append(key, value, new CookieOptions{ Expires = DateTime.Now.AddMinutes(minutes) }); } /// <summary> /// 删除指定的cookie /// </summary> /// <param name="key">键</param> protected void DeleteCookies(string key) { HttpContext.Response.Cookies.Delete(key); } /// <summary> /// 获取cookies /// </summary> /// <param name="key">键</param> /// <returns>返回对应的值</returns> protected string GetCookies(string key) { HttpContext.Request.Cookies.TryGetValue(key, out string value); if (string.IsNullOrEmpty(value)) value = string.Empty; return value; } } |
from:http://www.cnblogs.com/dawenyang/archive/2018/06/25/9223331.html
View Details在ASP.NET中，使用负载均衡时，可以通过ServerVariables获取客户端的IP地址。
|
1 |
var ip = request.ServerVariables["HTTP_X_FORWARDED_FOR"]; |
但在ASP.NET Core中没有ServerVariables的对应实现，需要换一种方式，可以在HttpContext.Request.Headers中获取，需要注意的是key与ServerVariables方式不一样，ServerVariables中是"HTTP_X_FORWARDED_FOR"，HttpContext.Request.Headers中是"X-Forwarded-For"，示例代码如下：
|
1 |
var ip = context.Request.Headers["X-Forwarded-For"].FirstOrDefault(); |
完整的扩展方法实现如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
public static class HttpContextExtension { public static string GetUserIp(this HttpContext context) { var ip = context.Request.Headers["X-Forwarded-For"].FirstOrDefault(); if (string.IsNullOrEmpty(ip)) { ip = context.Connection.RemoteIpAddress.ToString(); } return ip; } } |
from:https://www.cnblogs.com/dudu/p/5972649.html
View Details.NET Core默认不支持GB2312，使用Encoding.GetEncoding(“GB2312”)的时候会抛出异常。 解决方案是手动安装System.Text.Encoding.CodePages包(Install-Package System.Text.Encoding.CodePages), 然后在Starup.cs的Configure方法中加入Encoding.RegisterProvider(CodePagesEncodingProvider.Instance),接着就可以正常使用Encoding.GetEncoding(“GB2312”)了。 from:http://www.mamicode.com/info-detail-2225481.html
View Details最近在用.net core写一个爬虫抓取网页上的数据，碰到了网页编码是GBK的页面，抓取的数据都是乱码，当使用Encoding.GetEncoding(“GBK”)的时候抛出了异常： 'GBK' is not a supported encoding name. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method. Parameter name: name 当改用GB2312的时候也抛出了同样的异常： 'GB2312' is not a supported encoding name. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method. Parameter name: name 从异常上来看是不支持GB2312和GBK。而且提到了需要注册EncodingProvider的方法。CodePagesEncodingProvider定义在NuGet包“System.Text.Encoding.CodePages”之中。所以我们就需要添加System.Text.Encoding.CodePages的依赖。然后在Project.json中添加 { "dependencies": { "System.Text.Encoding.CodePages": "4.0.1-rc2-24027" } } 在代码中还需要添加Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);如图： 再次启动就可以可以使用GB2312 from:https://www.cnblogs.com/liemei/p/7884172.html
View Details你大概知道System.Drawing，它是一个执行图形相关任务的流行的API，同时它也不属于.NET Core的一部分。最初是把.NET Core作为云端框架设计的，它不包含非云端相关API。另一方面，.NET Core是跨平台框架，它不包含任何操作系统特定的API，例如Windows上的Active Directory活动目录 。再者，.NET Core也不包括类似，作为.NET framework一部分的，ConfigurationManager这样的诸多API。 在我之前的文章中，我已经描述了如何将这些API用于.NET Core和.NET标准应用程序。 为了实现这一点，有一个称为Windows Compatibility Pack的元包。但是，这个元包包含许多与Windows相关的API（作为包分发）。在这个元包里面有一个System.Drawing.Common包。 为了在.NET Core中使用绘图功能，请在Nuget包添加引用：
|
1 |
<PackageReference Include="System.Drawing.Common" Version="4.5.0-preview1-**" > |
在这之后，你将可以运行例如以下的代码。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
int x = 100; Image image = new Bitmap(2000, 1024); Graphics graph = Graphics.FromImage(image); graph.Clear(Color.Azure); Pen pen = new Pen(Brushes.Black); graph.DrawLines(pen, new Point[] { new Point(10,10), new Point(800, 900) }); graph.DrawString("Hello drawing from .NET Core :)", new Font(new FontFamily("DecoType Thuluth"), 20, FontStyle.Bold), Brushes.Blue, new PointF(150, 90)); image.Save("graph.jpeg", System.Drawing.Imaging.ImageFormat.Png); |
在你运行上述代码之后，你将看到如下图片： 下面是当前已经支持的字体列表：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 |
AGA Arabesque AGA Arabesque Desktop Agency FB Akhbar MT Algerian Arial Arial Black Arial Narrow Arial Rounded MT Bold Bahnschrift Bahnschrift Light Bahnschrift SemiBold Bahnschrift SemiLight Baskerville Old Face Bauhaus 93 Bell MT Berlin Sans FB Berlin Sans FB Demi Bernard MT Condensed Blackadder ITC Bodoni MT Bodoni MT Black Bodoni MT Condensed Bodoni MT Poster Compressed Bold Italic Art Book Antiqua Bookman Old Style Bookshelf Symbol 7 Bradley Hand ITC Britannic Bold Broadway Brush Script MT Calibri Calibri Light Californian FB Calisto MT Cambria Cambria Math Candara Castellar Centaur Century Century Gothic Century Schoolbook Chiller Colonna MT Comic Sans MS Consolas Constantia Cooper Black Copperplate Gothic Bold Copperplate Gothic Light Corbel Courier New Curlz MT DecoType Naskh DecoType Naskh Extensions DecoType Naskh Special DecoType Naskh Swashes DecoType Naskh Variants DecoType Thuluth Diwani Bent Diwani Letter Diwani Outline Shaded Diwani Simple Outline Diwani Simple Outline 2 Diwani Simple Striped Dosis Dubai Dubai Light Dubai Medium Ebrima Edwardian Script ITC Elephant Engravers MT Eras Bold ITC Eras Demi ITC Eras Light ITC Eras Medium ITC Farsi Simple Bold Farsi Simple Outline Felix Titling Footlight MT Light Forte Franklin Gothic Book Franklin Gothic Demi Franklin Gothic Demi Cond Franklin Gothic Heavy Franklin Gothic Medium Franklin Gothic Medium Cond Freestyle Script French Script MT FZShuTi FZYaoTi Gabriola Gadugi Garamond Georgia Gigi Gill Sans MT Gill Sans MT Condensed Gill Sans MT Ext Condensed Bold Gill Sans Ultra Bold Gill Sans Ultra Bold Condensed Gloucester MT Extra Condensed Goudy Old Style Goudy Stout Haettenschweiler Harlow Solid Italic Harrington High Tower Text HoloLens MDL2 Assets Impact Imprint MT Shadow Informal Roman Italic Outline Art Javanese Text Jokerman Juice ITC Kristen ITC Kufi Extended Outline Kufi Outline Shaded Kunstler Script Lato Lato Black Led Italic Font Leelawadee UI Leelawadee UI Semilight LiSu Lucida Bright Lucida Calligraphy Lucida Console Lucida Fax Lucida Handwriting Lucida Sans Lucida Sans Typewriter Lucida Sans Unicode Magneto Maiandra GD Malgun Gothic Malgun Gothic Semilight Marlett Matura MT Script Capitals Microsoft Himalaya Microsoft JhengHei Microsoft JhengHei Light Microsoft JhengHei UI Microsoft JhengHei UI Light Microsoft New Tai Lue Microsoft Office Preview Font Microsoft PhagsPa Microsoft Sans Serif Microsoft Tai Le Microsoft YaHei Microsoft YaHei Light Microsoft YaHei UI Microsoft YaHei UI Light Microsoft Yi Baiti MingLiU-ExtB MingLiU_HKSCS-ExtB Mistral Modern No. 20 Mongolian Baiti Monotype Corsiva Monotype Koufi Montserrat MS Gothic MS Office Symbol (de-de) Bold MS Office Symbol (de-de) Light MS Office Symbol Extralight MS Office Symbol Regular MS Office Symbol Semibold MS Office Symbol Semilight MS Outlook MS PGothic MS Reference Sans Serif MS Reference Specialty MS UI Gothic MT Extra Mudir MT MV Boli Myanmar Text Niagara Engraved Niagara Solid Nirmala UI Nirmala UI Semilight NSimSun OCR A Extended Old Antic Bold Old Antic Decorative Old Antic Outline Old Antic Outline Shaded Old English Text MT Onyx Oswald Palace Script MT Palatino Linotype Papyrus Parchment Perpetua Perpetua Titling MT Playbill PMingLiU-ExtB Poor Richard Pristina PT Bold Arch PT Bold Broken PT Bold Dusky PT Bold Heading PT Bold Mirror PT Bold Stars PT Separated Baloon PT Simple Bold Ruled Rage Italic Ravie Rockwell Rockwell Condensed Rockwell Extra Bold Script MT Bold Segoe MDL2 Assets Segoe Print Segoe Script Segoe UI Segoe UI Black Segoe UI Emoji Segoe UI Historic Segoe UI Light Segoe UI Semibold Segoe UI Semilight Segoe UI Symbol Showcard Gothic Simple Bold Jut Out Simple Indust Outline Simple Indust Shaded Simple Outline Pat SimSun SimSun-ExtB Sitka Banner Sitka Display Sitka Heading Sitka Small Sitka Subheading Sitka Text Snap ITC Source Sans Pro Source Sans Pro Black Source Sans Pro Semibold STCaiyun Stencil STFangsong STHupo STKaiti STLiti STSong STXihei STXingkai STXinwei STZhongsong Sylfaen Symbol Tahoma Tempus Sans ITC Times New Roman Trebuchet MS Tw Cen MT Tw Cen MT Condensed Tw Cen MT Condensed Extra Bold Verdana Viner Hand ITC Vivaldi Vladimir Script Webdings Wide Latin Wingdings Wingdings 2 Wingdings 3 YouYuan Yu Gothic Yu Gothic Light Yu Gothic Medium Yu Gothic UI Yu Gothic UI Light Yu Gothic UI Semibold Yu Gothic UI Semilight |
from:https://blog.csdn.net/u014654707/article/details/80630718
View Details摘要： 前言目前的应用系统，不管是企业级应用还是互联网应用，最终数据的一致性是每个应用系统都要面临的问题，随着分布式的逐渐普及，数据一致性更加艰难，但是也很难有银弹的解决方案，也并不是引入特定的中间件或者特定的开源框架能够解决的，更多的还是看业务场景，根据场景来给出解决方案。根据笔者最近几年的了解，总… 前言 目前的应用系统，不管是企业级应用还是互联网应用，最终数据的一致性是每个应用系统都要面临的问题，随着分布式的逐渐普及，数据一致性更加艰难，但是也很难有银弹的解决方案，也并不是引入特定的中间件或者特定的开源框架能够解决的，更多的还是看业务场景，根据场景来给出解决方案。根据笔者最近几年的了解，总结了几个点，更多的应用系统在编码的时候，更加关注数据的一致性，这样系统才是健壮的。 基础理论相关 说起事务，目前的几个理论，ACID事务特性，CAP分布式理论，以及BASE等，ACID在数据库事务中体现，CAP和BASE则是分布式事务的理论，结合业务系统，例如订单管理，例如仓储管理等，可以借鉴这些理论，从而解决问题。 ACID 特性 A（原子性）事务的原子操作单元，对数据的修改，要么全部执行，要么全部不执行； C（一致性）在事务开始和完成时，数据必须保持一致状态，相关的数据规则必须应用于事务的修改，以保证数据的完整性，事务结束时，所有的内部数据结构必须正确； I（隔离性）保证事务不受外部并发操作的独立环境执行； D（持久性）事务完成之后，对于数据的修改是永久的，即使系统出现故障也能够保持； CAP C（一致性）一致性是指数据的原子性，在经典的数据库中通过事务来保障，事务完成时，无论成功或回滚，数据都会处于一致的状态，在分布式环境下，一致性是指多个节点数据是否一致； A（可用性）服务一直保持可用的状态，当用户发出一个请求，服务能在一定的时间内返回结果； P（分区容忍性）在分布式应用中，可能因为一些分布式的原因导致系统无法运转，好的分区容忍性，使应用虽然是一个分布式系统，但是好像一个可以正常运转的整体 BASE BA: Basic Availability 基本业务可用性； S: Soft state 柔性状态； E: Eventual consistency 最终一致性； 最终一致性的几种做法 单数据库情况下的事务 如果应用系统是单一的数据库，那么这个很好保证，利用数据库的事务特性来满足事务的一致性，这时候的一致性是强一致性的。对于java应用系统来讲，很少直接通过事务的start和commit以及rollback来硬编码，大多通过spring的事务模板或者声明式事务来保证。 基于事务型消息队列的最终一致性 借助消息队列，在处理业务逻辑的地方，发送消息，业务逻辑处理成功后，提交消息，确保消息是发送成功的，之后消息队列投递来进行处理，如果成功，则结束，如果没有成功，则重试，直到成功，不过仅仅适用业务逻辑中，第一阶段成功，第二阶段必须成功的场景。对应上图中的C流程。 基于消息队列+定时补偿机制的最终一致性 前面部分和上面基于事务型消息的队列，不同的是，第二阶段重试的地方，不再是消息中间件自身的重试逻辑了，而是单独的补偿任务机制。其实在大多数的逻辑中，第二阶段失败的概率比较小，所以单独独立补偿任务表出来，可以更加清晰，能够比较明确的直到当前多少任务是失败的。对应上图的E流程。 业务系统业务逻辑的commit/rollback机制 这一点说的话确实不难，commit和rollback是数据库事务中的比较典型的概念，但是在系统分布式情况下，需要业务代码中实现这种，成功了commit，失败了rollback。 业务应用系统的幂等性控制 为啥要做幂等呢？ 原因很简单，在系统调用没有达到期望的结果后，会重试。那重试就会面临问题，重试之后不能给业务逻辑带来影响，例如创建订单，第一次调用超时了，但是调用的系统不知道超时了是成功了还是失败了，然后他就重试，但是实际上第一次调用订单创建是成功了的，这时候重试了，显然不能再创建订单了。 查询 查询的API，可以说是天然的幂等性，因为你查询一次和查询两次，对于系统来讲，没有任何数据的变更，所以，查询一次和查询多次一样的。 MVCC方案 多版本并发控制，update with condition，更新带条件，这也是在系统设计的时候，合理的选择乐观锁，通过version或者其他条件，来做乐观锁，这样保证更新及时在并发的情况下，也不会有太大的问题。例如update table_xxx set name=#name#,version=version+1 where version=#version# ,或者是 update table_xxx set quality=quality-#subQuality# where quality-#subQuality# >= 0 。 单独的去重表 如果涉及到的去重的地方特别多，例如ERP系统中有各种各样的业务单据，每一种业务单据都需要去重，这时候，可以单独搞一张去重表，在插入数据的时候，插入去重表，利用数据库的唯一索引特性，保证唯一的逻辑。 分布式锁 还是拿插入数据的例子，如果是分布是系统，构建唯一索引比较困难，例如唯一性的字段没法确定，这时候可以引入分布式锁，通过第三方的系统，在业务系统插入数据或者更新数据，获取分布式锁，然后做操作，之后释放锁，这样其实是把多线程并发的锁的思路，引入多多个系统，也就是分布式系统中得解决思路。 删除数据 删除数据，仅仅第一次删除是真正的操作数据，第二次甚至第三次删除，直接返回成功，这样保证了幂等。 插入数据的唯一索引 插入数据的唯一性，可以通过业务主键来进行约束，例如一个特定的业务场景，三个字段肯定确定唯一性，那么，可以在数据库表添加唯一索引来进行标示。 API层面的幂等 这里有一个场景，API层面的幂等，例如提交数据，如何控制重复提交，这里可以在提交数据的form表单或者客户端软件，增加一个唯一标示，然后服务端，根据这个UUID来进行去重，这样就能比较好的做到API层面的唯一标示。 状态机幂等 在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机，就是业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，这时候，如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。 异步回调机制的引入 A应用调用B，在同步调用的返回结果中，B返回成功给到A，一般情况下，这时候就结束了，其实在99.99%的情况是没问题的，但是有时候为了确保100%，记住最起码在系统设计中100%，这时候B系统再回调A一下，告诉A，你调用我的逻辑，确实成功了。其实这个逻辑，非常类似TCP协议中的三次握手。上图中的B流程。 类似double check机制的确认机制 还是上图中异步回调的过程，A在同步调用B，B返回成功了。这次调用结束了，但是A为了确保，在过一段时间，这个时间可以是几秒，也可以是每天定时处理，再调用B一次，查询一下之前的那次调用是否成功。例如A调用B更新订单状态，这时候成功了，延迟几秒后，A查询B，确认一下状态是否是自己刚刚期望的。上图中的D流程。 总结 上面的几点总结，更多的在业务系统中体现，在超复杂的系统中，数据的一致性，不是说简单的引入啥中间件能够解决的，更多的是根据业务场景，来灵活应对。 from:https://www.cnblogs.com/BrightMoon/p/5622618.html
View Details