上一篇文章中我们讲解了利用数据库分区与冷热分离的方式来优化存储，虽然解决了查询速度慢的问题，但是在海量数据情况下依然会出现查询缓慢问题，并且部分系统中的冷热数据也是需要频繁或同时查询的。那么，这篇文章中我将带领大家来学习一下如何在设计系统架构时解决海量的数据存储与查询。
在本地事务这篇文章里我们讲到了数据库事务必须保证ACID，在2PC这篇文章里，我们探讨了跨数据库事务是如何保证ACID的。
缓存的读写策略。你可能觉得缓存的读写很简单，只需要优先读缓存，缓存不命中就从数据库查询，查询到了就回种缓存。实际上，针对不同的业务场景，缓存的读写策略也是不同的。
据了解，此次更新是为了修复phpmyadmin未鉴权，可通过特定地址直接登陆数据库的严重Bug。存在安全漏洞的面板据悉为linux面板7.4.2版本，Windows面板6.8版本。（就是宝塔的程序员缓存了phpmyadmin的密码 /pma 未授权访问，前提是你在此之前需要从宝塔面板自动登录过phpmyadmin！！！）
在这里需要注意的有两点：第一、在目标数据库中表如果有非空字段，而在源数据库中某个字段的值为空，则同步不会成功（简单点说如果目标数据库中的表有一个字段设置为不允许为NULL，而源数据库中的字段有NULL值。)
读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。
虽然可能大部分文章都有介绍过，但为了文章的完整性，我们还是从 redo log 和 binlog 的区别聊起。
对于高并发的业务场景，常用的技术手段包括黑白名单、限流防刷、熔断降级、兜底、线程隔离、多级缓存（客户端、CDN、NGINX、内存缓存、分布式缓存）等等。这些手段相互结合，才能应对高并发场景下的各种细分场景。本文总结了缓存方案需要考虑的几个问题。
主从复制 原理 数据库有个bin-log二进制文件, 记录了所有的sql语句. 主从复制就是从主数据库中将bin-log二进制文件复制到从数据库, 再执行一遍. 过程 整个过程需要三个进程进行实现. binlog输出进程: 每当有从库连接到主库的时候, 主库都会创建一个线程然后发送binlog内容到从库. 在从库里, 当复制开始的时候, 从库会创建两个线程来处理. 从库I/O线程: 当START SLAVE语句在从库开始执行之后, 从库创建一个I/O进程, 该进程连接到主库并请求主库发送binl
我们都知道，数据库是用于存取数据的。然而，存取数据会涉及到磁盘I/O的读写操作，这使得I/O读写成为数据库系统的主要性能瓶颈。为了解决这个问题，MySQL数据库采用了许多内存管理技术来优化数据库操作，包括内存优化查询、排序以及写入操作。
在EF中，使用CodeFirst给实体添加约束的时候，使用NeGut控制台进行更新到数据库中，先使用add-migration migrationName命令进行创建（migrationName是进行更新的名字），然后使用Update-Database进行更新到数据库，此时报出问题：
InnoDB 主要包括了内存池、后台线程以及存储文件。内存池又是由多个内存块组成的，主要包括缓存磁盘数据、redo log 缓冲等；后台线程则包括了 Master Thread、IO Thread以及 Purge Thread 等；由 InnoDB 存储引擎实现的表的存储结构文件一般包括表结构文件（.frm）、共享表空间文件（ibdata1）、独占表空间文件（ibd）以及日志文件（redo文件等）等。
https://github.com/xiaomoinfo/SpringBootUnity
为了提升服务的性能，我们一般会把热点放进缓存，那么这些热点数据就同时存在于数据库和缓存中，缓存中的数据和数据库中的数据要保持一致，这便是缓存一致性问题。
订单管理系统是很多公司，特别是电商公司最常用的内部系统之一。订单管理系统的使用者通常是仓管或者运营人员，它常被用于管理用户订单，比如添加或者修改一条发货记录，与快递 API 集成以便自动更新订单号等场景。
当服务使用关系型数据库已经达到性能瓶颈的时候我们应该怎么办，数据库已经分片了，也分库分表了，索引什么也都极致了（一般不可能）但是还是扛不住高流量。有点经验的同学都会说：“加缓存，上redis or 直接应用内存（缓存）“。
日志系统主要有redo log(重做日志)和binlog(归档日志)。redo log是InnoDB存储引擎层的日志，binlog是MySQL Server层记录的日志， 两者都是记录了某些操作的日志(不是所有)自然有些重复（但两者记录的格式不同）。
时间过的很快，一眨眼一年时间就过去了。过去一年里，我也和群里的不少朋友一起成长，互相学习到不少东西！下面总结一些，我们经常在群里讨论的一些关于 MySQL 的知识点。
缓存，是一种存储数据的组件，它的作用是让对数据的请求更快地返回，是一种常见的空间换时间的性能优化手段。
使用EF Core Migrations可以使Entity & DbContext的配置与数据库保持一致，Migrations可以非常容易的将创建和更新数据库，当一个项目在开发过程中时，程序员能保证实体更新，因此他们需要运行Migration保证数据库是最新
问题 1.在使用EntityFramework访问Mysql的时候，使用迁移来生成数据库或者更新数据库时候会遇到一些问题 2.EntityFramework.Extended对Mysql的支持不是很完全，其中修改是无法直接使用的需要做一些处理 3.EntityFramework.Extended如何跟EntityFramework其他的操作在一个事物里面（针对网友zengfanlin 问题） 解决方案 1.首先解决第一个问题 准备条件：用Nuget下载Mysql.Data.Entity（可以将依赖连同下载）
脏数据检查： 什么是脏数据？脏数据并不是废弃和无用的数据，而是状态前后发生变化的数据。我们看下面的代码： 当事务提交时，Hibernate会对session中的PO(持久化对象)进行检测，判断持久化对象的状态是否发生了改变，如果发生了改变就会将改变更新到数据库中。这里就存在一个问题，Hibernate如何来判断一个实体对象的状态前后是否发生了变化。也就是说Hibernate是如何检查出一个数据已经变脏了。 通常脏数据的检查有如下两种办法： A、数据对象监控： 数据对象监控是通过拦截器对数据对象的setter
WordPress后台一般都可以直接一键升级，但是也存在一些情况导致无法自动升级，所以，简单说一下 wordpress 手动还原到旧版本 和 WordPress 手动更新到最新版的方法，其实，操作都是一样的，可以说是手动更新到任意版本。
在高并发的场景下，大量的请求直接访问MySQL很容易造成性能问题。所以，我们都会用Redis来做数据的缓存，削减对数据库的请求。但是，MySQL和Redis是两种不同的数据库，如何保证不同数据库之间数据的一致性就非常关键了。
本期课程给大家谈谈数据一致性，因为经常有同学问到，今天就给大家讲讲，数据一致性大致可分为三类：
事务是访问并更新数据库中各个数据项的一个程序执行单元。在事务操作中，要不都做修改，要么都不做。
缓存系统一般设计简单，功能单一，所以Redis吞吐量能是MySQL几倍~几十倍，对于互联网读多写少的高并发场景已不可或缺。
我以为生活是猫吃鱼，狗吃肉，奥特曼打小怪兽。现实确是鼠整猫，羊耍狼，俩熊玩死光头强！这个世界这么疯狂，让我们如何坚强！
很多场景中，服务端需要对用户的请求进行验证，比如QQ登录模块、统计工具的数据收集模块、品牌广告对应id的match等。针对不同的场景，可以有不同的验证方法，本文将介绍工程中常用的几种。
魏艾斯博客的 wordpress 更新比较慢，在 3.7 版本停留了很久，后来手动升级到 4.73 版本和 4.86 版本，这又过去了半年时间，wordpress 官方版本已经更新到 4.95en 了，于是就更新到了 4.94cn 版本，记录一下手动更新过程和注意事项。 之前写过一个WordPress 手动升级更新方法，里面有一些遗漏的地方，就在本文补充完善一下。更新 wodrepss 到最新版本可以及时跟上官方程序优化和补丁，好处多多。 更新 wordpress 之前切记备份网站文件和数据库，这是老魏敢折
先介绍学心理学的时候记住的两个把妹秘籍: 1>巴甫洛夫把妹法:巴甫洛夫的狗的反射试验上学的时候大家都应该学过，天天给狗喂食的时候摇铃，后来不喂食只摇铃狗还是分泌唾液。应用到把妹这个非常有实际意义的事情上面就是：每天给妹子送早晨，等人家形成了习惯，突然不送了，人家就开始觉得不自在了，开始各种想这个男孩纸~~ 2>吊桥效应:在吊桥上，由于危险的情境，人们会不自觉地心跳加快，错把由这种情境引起的心跳加快理解为对方使自己心动，才产生的生理反应，故而对对方滋生出爱情的情愫。 心理学是门很实用的学问吧[偷笑
本文主要探讨MySQL InnoDB 引擎下ACID的实现原理，对于诸如什么是事务，隔离级别的含义等基础知识不做过多阐述。
数据库恢复的策略，是使用最近的一次备份来实现数据库的还原，然后使用归档日志和联机日志将数据库恢复到最新或特定状态。
最近一直在写《手撕MySQL系列》文章，我发现自己的切入点有一些问题，虽尝试深入探究MySQL中的一些关键特性，但对于MySQL的知识掌握不太能够形成较好的体系化的知识网络。我感到在对全局了解不够清晰的时候，去深究一个知识点往往会事倍功半。所以打算通过这篇文章，分析SQL语句从头到尾的执行，串连一下MySQL当中的基础知识点。
DBUnit是一个基于junit扩展的数据库测试框架。它提供了大量的类对与数据库相关的操作进行了抽象和封装。它通过使用用户自定义的数据集以及相关操作使数据库处于一种可知的状态，从而使得测试自动化、可重复和相对独立。虽然不用dbunit也可以达到这种目的，但是我们必须为此付出代价（编写大量代码，测试及维护），既然有了这么优秀的开源框架，我们又何必再造轮子。
不同存储技术的访问时间差异很大，从 计算机层次结构 可知，通常情况下，从高层往底层走，存储设备变得更慢、更便宜同时体积也会更大，CPU 和内存之间的速度存在着巨大的差异，此时就会想到计算机科学界中一句著名的话：计算机科学的任何一个问题，都可以通过增加一个中间层来解决。
—1— 前言 在高并发的场景下，大量的请求直接访问Mysql很容易造成性能问题。所以，我们都会用Redis来做数据的缓存，削减对数据库的请求。但是，Mysql和Redis是两种不同的数据库，如何保证不同数据库之间数据的一致性就非常关键了。 —2— 数据不一致的原因 1.导致数据不一致的原因 在高并发的业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。 所以，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问MySQL等数据库。 读取缓存步骤一般没有什么问题，但是一旦涉及到数
使用外部的其它高级语言（如JAVA）拼接后再交由数据库运行也是一种选择，其灵活性较高，但因为JAVA缺乏对集合计算的支持。完毕这些准备工作并不轻松。
因为数据库更新、缓存更新这2个动作不是原子的，在高并发操作时，这2个动作直接会插入其他动作。
我们都知道，当用户修改了数据，数据页在内存中修改后并不是每次都刷新到磁盘上。checkpoint之前的数据页保证一定落盘了，这也代表这这部分redolog可以被覆盖了，checkpoint之后的之后的数据有可能落盘，也有可能没有落盘，所以在进行崩溃恢复时，checkpoint之后的日志还是需要被使用的。innodb会依据脏页的刷新情况，定期推进checkpoint，从而减少数据库崩溃恢复的时间。
在上一片文章中，我们说innodb的内存优化主要是通过多buffer pool size的优化，首先是lru链表的young和old区，以及之间的数据页的迁移的时间优化。因为我们执行一条sql，其实是在内存中做这件事情的，做完毕之后会加入的dolog中，然后后台线性会将其写入磁盘，所有这个缓存的大小就成为性能的重要影响因素。除此之外，调整old区的大小也可以让热点数据不易从buffer pool中淘汰，我们可以通过设置innodb_old_blocks_pct去设置old区的比例。当然我们也可以通过old区的最小淘汰时间innodb_old_blocks_time来让更多的数据能够留在热点区域内。当然由于线程对innodb缓存池的访问是互斥的，所以并发比较大的时候，容易出现瓶颈，所以在这里可以设置innodb_buffer_instances，这样buffer_pool_size就会平分到每个instance上。对于长时间不用或者要被淘汰的数据页，也有操作的方式，其提供了innodb_io_capacity和innodb_max_dirty_pages_pct分别表示一秒需要刷新到磁盘的io次数和要进行数据回写磁盘的触发上线，默认值是75%。
在互联网项目开发中，缓存的应用是非常普遍了，缓存可以帮助页面提高加载速度，减少服务器或数据源的负载。
WordPress是一种使用PHP语言开发的博客平台，用户可以在支持PHP和MySQL数据库的服务器上架设属于自己的网站，也可以把 WordPress当作一个内容管理系统（CMS）来使用。
最新比较闲，为了学习下Android的开发构建ASP.NET MVC4+EF5+EasyUI+Unity2.x注入的后台管理系统（1）-前言与，虽然有点没有目的的学习，但还是了解了Android的基本
RUF MVC5 Repositories Framework Generator代码生成工具介绍和使用 功能介绍 这个项目经过了大半年的持续更新到目前的阶段基本稳定 所有源代码都是开源的，在github https://github.com/neozhu/MVC5-Scaffolder 共享 整个项目结构，技术框架完全是基于http://genericunitofworkandrepositories.codeplex.com/ 实现。 轻量级的N层架构，Unit Of Work and Reposit
一般在项目中，最消耗性能的地方就是后端服务的数据库了。而数据库的读写频率常常都是不均匀分布的，大多情况是读多写少，并且读操作（select）还会有一些复杂的判断条件，比如 like、group、join 等等，这些语法是非常消耗性能的，所有会出现很多的慢查询，因此数据库很容易在读操作的环节遇到瓶颈。
如果缓存集中在一段时间内失效，发生大量的缓存穿透，所有的查询都落在数据库上，造成了缓存雪崩
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
