为什么要提这个呢，因为Redis主从库目的呢其实就是为了实现高可靠。上篇文章中我们说过Redis的AOF、RDB日志其实就是为了减少数据丢失，这是高可靠的一部分。
master服务器会开启一个后台进程用于将redis中的数据生成一个rdb文件，与此同时，服务器会缓存所有接收到的来自客户端的写命令（包含增、删、改），当后台保存进程处理完毕后，会将该rdb文件传递给slave服务器，而slave服务器会将rdb文件保存在磁盘并通过读取该文件将数据加载到内存，在此之后master服务器会将在此期间缓存的命令通过redis传输协议发送给slave服务器，然后slave服务器将这些命令依次作用于自己本地的数据集上最终达到数据的一致性。
sql server 作为目前主流的数据库，用户遍布世界各地。sql server也有一些比较成熟的主备方案，目前主要有：复制模式(发布-订阅模式)、镜像传输模式、日志传输模式、故障转移集群。后面会一一介绍介绍各自的优缺点。
在某些情况下，作为DBA，您需要将模式和特定表的内容从数据库复制到同一实例中或在不同的SQL实例中，例如从生产数据库中复制特定表到开发人员以进行测试或排除故障。 SQL Server提供了许多方法，可以用来执行表的数据和模式复制过程。为了研究这些方法中的每一个，我们将考虑下面的场景: 托管SQL服务器:localhost。这两个数据库都驻留在同一个SQL Server 2014实例中。 源数据库:AdventureWorks2012。 目标数据库:SQLShackDemo。 将从源数据库复制到目标数据库的表
通过持久化功能，Redis保证了即使在服务器重启的情况下也不会丢失（或少量丢失）数据，因为持久化会把内存中数据保存到硬盘上，重启会从硬盘上加载数据。 但是由于数据是存储在一台服务器上的，如果这台服务器出现硬盘故障等问题，也会导致数据丢失。
让我们设计一个文件托管服务，比如Dropbox或Google Drive。云文件存储允许用户在远程服务器上存储数据。通常，这些服务器由云存储提供商维护，并通过网络（通常通过互联网）提供给用户。用户每月支付云数据存储费用。类似服务：OneDrive、Google Drive
转：http://blog.csdn.net/qq394829044/article/details/53203645
数据库镜像维护一个数据库的两个副本，这两个副本必须驻留在不同的 SQL Server 数据库引擎服务器实例上。 通常，这些服务器实例驻留在不同位置的计算机上。 启动数据库上的数据库镜像操作时，在这些服务器实例之间形成一种关系，称为“数据库镜像会话”。
在上一个文档“为什么选择CouchDB？”中，我们看到CouchDB的灵活性使我们能够随着应用程序的增长和变化而发展数据。在本主题中，我们将探讨CouchDB的“细化”工作如何提高应用程序的简单性，并帮助我们自然地构建可扩展的分布式系统。
在一个生产系统中，通常都需要用高可用方案来保证系统的不间断运行。PostgreSQL 本身不支持任何多主群集解决方案，例如MySQL或Oracle。尽管如此，仍有许多商业和社区产品提供此实现，以及其他产品，例如PostgreSQL的复制或负载平衡。
数据库服务器可以一起工作，这样如果主要的服务器失效则允许一个第二服务器快速接手它的任务（高可用性），或者可以允许多个计算机提供相同的数据（负载均衡）。理想情况下，数据库服务器能够无缝地一起工作。提供静态网页服务的网页服务器可以非常容易地通过把网页请求均衡到多个机器来组合。事实上，只读的数据库服务器也可以相对容易地组合起来。不幸的是，大部分数据库服务器收到的请求是读/写混合的，并且读/写服务器更难于组合。这是因为尽管只读数据只需要在每台服务器上放置一次，但对于任意服务器的一次写动作却必须被传播给所有的服务器，这样才能保证未来对于那些服务器的读请求能返回一致的结果。
Redis 的复制功能分为同步（sync）和命令传播（command propagate）这两个操作
1、大型网站的自强之路 当年马云筹办阿里巴巴的时候并没有说我要做个大型网站，搞个双11，成交额做到千亿级别；马化腾也没有说以后我要做个通讯工具，让13亿乃至更多用户都成为我们的用户……我们现如今看到的各个大型网站或产品都是一步步踏踏实实走过来的，在各种坑和故障中成长起来的。 1.1、一台电脑就是服务器 做过课程设计或者毕业设计的计算机相关的同学都应该有过搭建项目的经验。画一堆界面，结合js和后台实现数据的展现，当然还要有数据来源——数据库，启动一个容器比如tomcat，那么我们就可以在本机上访问我们的网站了
又赶上一年一度的金九银十的日子，这段期间的招聘岗位相对前几个月会多些，如果在目前公司没有进步、没有前途时，这段时间可以准备一下，去外面看看机会。不过在外面找工作时，可以提前在网上看看招聘信息，看看自己是否达到公司要求。如果多看下高薪资的技术人员招聘要求时，就会发现对三高都有一定的要求，比如下面一家公司的要求就对高并发、高负载和高可用性系统设计要有开发经验。
MySQL 主从复制（Master-Slave Replication）是一种数据复制技术，用于在多个数据库服务器之间的数据同步。在主从复制架构中，一个服务器被设置为主服务器（Master），充当数据源，其他服务器被设置为从服务器（Slave），用来复制主服务器的数据。
如题 请大家讨论一下网游服务器端结构设计方面的问题。 希望大家畅所欲言，能说说细节更好。 还有关于网络游戏其他方面的问题也可以。 在此先摘篇文章 随着网游从业者的规模和需求不断扩大，越来越多的朋友进入了网游开发这个领域，使得市场中网游开发技术相关的需求量迅猛增长。目前，（网游）网络游戏行业比较紧缺的是具有较深技术功底的“专家型”开发者，这主要包括两个方面：服务器端设计人员以及客户端设计人员。对于网络游戏而言，由于其主要的游戏逻辑计算是在服务器端完成的，数据同步与广播信息的传递也是通过服务器完成的，所以，是否拥有一个有经验的服务器端设计人员已经成为一款网游产品能否成功的关键之一。鉴于此，本文将试图就网游服务器设计的一系列问题展开讨论和总结，笔者将结合自己的开发经验和体会，将其中各方面内容逐一呈现。希望能够对以下三类人员有所帮助： 有一定网络编程基础、准备进入（网游）网络游戏行业作服务器端设计的人员； 正在从事网游服务器设计的人员； 网游项目的技术负责人。 由于网游服务器的设计牵涉到太多内容，比如：网络通信方面、人工智能、数据库设计等等，所以本文将重点从网络通信方面的内容展开论述。谈到网络通信，就不能不涉及如下五个问题： 1、 常见的网游服务通信器架构概述 2、 网游服务器设计的基本原则 3、 网游服务器通信架构设计所需的基本技术 4、 网游服务器通信架构的测试 5、 网游服务器通信架构设计的常见问题 下面我们就从第一个问题说起： 常见的网游服务器通信架构概述 目前，国内的网游市场中大体存在两种类型的网游游戏：MMORPG（如：魔兽世界）和休闲网游（如：QQ休闲游戏和联众游戏，而如泡泡堂一类的游戏与QQ休闲游戏有很多相同点，因此也归为此类）。由于二者在游戏风格上的截然不同，导致了他们在通信架构设计思路上的较大差别。下面笔者将分别描述这两种网游的通信架构。 1．MMORPG类网游的通信架构 网游的通信架构，通常是根据几个方面来确定的：游戏的功能组成、游戏的预计上线人数以及游戏的可扩展性。 目前比较通用的MMORPG游戏流程是这样的： a. 玩家到游戏官方网站注册用户名和密码。 b. 注册完成后，玩家选择在某一个区激活游戏账号。 c. 玩家在游戏客户端中登录进入已经被激活的游戏分区，建立游戏角色进行游戏。 通常，在这样的模式下，玩家的角色数据是不能跨区使用的，即：在A区建立的游戏角色在B区是无法使用的，各区之间的数据保持各自独立性。我们将这样独立的A区或B区称为一个独立的服务器组，一个独立的服务器组就是一个相对完整的游戏世界。而网游服务器的通信架构设计，则包括了基于服务器组之上的整个游戏世界的通信架构，以及在一个服务器组之内的服务器通信架构。 我们先来看看单独的服务器组内部的通信是如何设计的。 一个服务器组内的各服务器组成，要依据游戏功能进行划分。不同的游戏内容策划会对服务器的组成造成不同的影响。一般地，我们可以将一个组内的服务器简单地分成两类：场景相关的（如：行走、战斗等）以及场景不相关的（如：公会聊天、不受区域限制的贸易等）。为了保证游戏的流畅性，可以将这两类不同的功能分别交由不同的服务器去各自完成。另外，对于那些在服务器运行中进行的比较耗时的计算，一般也会将其单独提炼出来，交由单独的线程或单独的进程去完成。 各个网游项目会根据游戏特点的不同，而灵活选择自己的服务器组成方案。经常可以见到的一种方案是：场景服务器、非场景服务器、服务器管理器、AI服务器以及数据库代理服务器。 以上各服务器的主要功能是： 场景服务器：它负责完成主要的游戏逻辑，这些逻辑包括：角色在游戏场景中的进入与退出、角色的行走与跑动、角色战斗（包括打怪）、任务的认领等。场景服务器设计的好坏是整个游戏世界服务器性能差异的主要体现，它的设计难度不仅仅在于通信模型方面，更主要的是整个服务器的体系架构和同步机制的设计。 非场景服务器：它主要负责完成与游戏场景不相关的游戏逻辑，这些逻辑不依靠游戏的地图系统也能正常进行，比如公会聊天或世界聊天，之所以把它从场景服务器中独立出来，是为了节省场景服务器的CPU和带宽资源，让场景服务器能够尽可能快地处理那些对游戏流畅性影响较大的游戏逻辑。 服务器管理器：为了实现众多的场景服务器之间以及场景服务器与非场景服务器之间的数据同步，我们必须建立一个统一的管理者，这个管理者就是服务器组中的服务器管理器。它的任务主要是在各服务器之间作数据同步，比如玩家上下线信息的同步。其最主要的功能还是完成场景切换时的数据同步。当玩家需要从一个场景A切换到另一个场景B时，服务器管理器负责将玩家的数据从场景A转移到场景B，并通过协议通知这两个场景数据同步的开始与结束。所以，为了实现这些内容繁杂的数据同步任务，服务器管理器通常会与所有的场景服务器和非场景服务器保持socke
网上搜索“数据库同步”，会搜到许多有关同步数据库数据的信息, 同时, 关于同步数据库模式结构的指令不太普遍。 更改数据库结构会带来破坏现有数据的固有风险。 因此，同步数据库结构时必须格外小心
主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库，主数据库一般是准实时的业务数据库。您看，像在mysql数据库中，支持单项、异步赋值。在赋值过程中，一个服务器充当主服务器，而另外一台服务器充当从服务器。此时主服务器会将更新信息写入到一个特定的二进制文件中。并会维护文件的一个索引用来跟踪日志循环。这个日志可以记录并发送到从服务器的更新中去。当一台从服务器连接到主服务器时，从服务器会通知主服务器从服务器的日志文件中读取最后一次成功更新的位置。然后从服务器会接收从哪个时刻起发生的任何更新，然后锁住并等到主服务器通知新的更新
数据库的弹性伸缩与WebServer相比，复杂了很多倍，对于WebServer的弹性伸缩直接用负载均衡+弹性伸缩组件搞定。但对于数据库的扩容、缩容将面临数据不一致等问题。这些问题在互联网企业上云是必须解决的，为提升我们对大型业务上云的理解，我们今天一起来看一看。
当使用多台服务器架设成集群之后，我们通过负载均衡的方式，同一个用户（或者ip）访问时被分配到不同的服务器上，假设在A服务器登录，如果在B服务器拿不到用户的登录信息session。这时访问到B服务器时就出现未登录情况。
Q：为啥要引入主从同步机制？ A：防止业务数据库突然宕掉，不能快速的恢复业务正常运行，有利于数据库架构的健壮性，提升访问速度，方便运维保证的数据物理安全(容灾备份)；
异步提交是一个允许事务能更快完成的选项，代价是在数据库崩溃时最近的事务会丢失。在很多应用中这是一个可接受的交换。
在网络层的背后，每一个业务都需要数据的支撑，数据库的优化在整个系统中就显得至关重要了。 虽然 NoSQL 在并发性能上要优于传统的 DBA，但由于 MySQL 在扩展性等方面的优势，MySQL 依然作为企业级数据存储的首选。
Redis集群是一种通过将多个Redis节点连接在一起以实现高可用性、数据分片和负载均衡的技术。它允许Redis在不同节点上同时提供服务，提高整体性能和可靠性。在Redis中提供集群方案总共有三种：主从复制、哨兵模式、Redis分片集群。这些都是目前主流经典的集群模式，redis做集群的好处：
本文将详细介绍如何使用Self-hosted LiveSync插件搭建私有的Obsidian云同步服务器，来实现一个免费的、私有的、跨平台的、允许多端即时同步的强力笔记软件。
GIT地址：https://gitee.com/michlee/mysql-sync
我们在平时工作中，使用最多的数据库就是 MySQL 了，随着业务的增加，如果单单靠一台服务器的话，负载过重，就容易造成宕机。
前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训，两天12个小时信息量非常大，知识的广度和难度也非常大，培训完后我很难完整理出全部听到的知识，今天我换了个思路是回味这次培训，这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程。 首先我们要思考一个问题，什么样的网站才是大型网站，从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标，懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标，如果按这些标准那么像hao123这样的网
作者：夏天的森林 出处：cnblogs.com/sharpxiajun/p/4237704.html 一，题记 前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训，两天12个小时信息量非常大，知识的广度和难度也非常大，培训完后我很难完整理出全部听到的知识，今天我换了个思路是回味这次培训，这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程。 二，什么网站是大型网站 首先我们要思考一个问题，什么样的网站才是大型网站，从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认
如转载，请注明出处：http://blog.csdn.net/robinson_0612/archive/2009/11/04/4769060.aspx
针对当前远程容灾备份系统普遍造价高昂的缺点，技术人员提出了一种通过基于Linux系统下的Rsync（Remote Synchronize）远程同步框架进行改进，采用节点间数据复制技术实现数据库远程备份方案。 根据容灾备份系统对备份类别的要求程度，数据库备份系统可以分为数据级备份和应用级备份。数据备份是指建立一个异地的数据备份系统，该系统是对原本地系统关键应用数据实时复制。当出现故障时，可由异地数据系统迅速恢复本地数据从而保证业务的连续性。应用级备份比数据备份层次更高，即在异地建立一套完整的、与本地数据库系统
1.利用MySQL自身的数据库同步功能 2.利用MySQL数据库的特性(数据库存在固顶目录,并且以文件形式存储),进行数据库目录同步以达到数据同步目的 3.利用专用的MySQL数据库同步软件
保证redis高可用机制需要redis主从复制、redis持久化机制、哨兵机制、keepalived等的支持。
一个工程对应一个归档包(war)，这个war包 包含了该工程的所有功能。我们成为这种应用为单体应用，也就是我们常说的单体架构。具体描述: 就是在我们的一个war包种，聚集了各种功能以及资源，比如JSP,JS,CSS等。
Redis 作为缓存服务器是众多企业中的选择之一，虽然该技术很成熟但也是存在一定的问题。就是缓存带来的缓存穿透，缓存击穿，缓存失效问题，继而引用分布式锁。
MySQL主从复制(Master-Slave)也叫AB复制，Mysql作为目前世界上使用最广泛的免费数据库，相信所有从事系统运维的工程师都一定接触过。但在实际的生产环境中，由单台Mysql作为独立的数据库是完全不能满足实际需求的，无论是在安全性，高可用性以及高并发等各个方面。因此，一般来说都是通过主从复制（Master-Slave）的方式来同步数据，再通过读写分离（MySQL-Proxy）来提升数据库的并发负载能力这样的方案来进行部署与实施的。
MySQL 是最受欢迎的关系型数据库管理系统之一，被广泛应用于各种业务系统。主从复制是MySQL 的重要能力，用于实现数据冗余、提高可用性和性能。了解MySQL主从复制，可以更好地管理和优化数据库，为业务系统提供更强大的支持。
Mysql复制概念说明 Mysql内建的复制功能是构建大型，高性能应用程序的基础。将Mysql的数据分布到多个系统上去，这种分布的机制，是通过将Mysql的某一台主机的数据复制到其它主机（slaves）上，并重新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从
随着数据量的增大，读写并发的增加，系统可用性要求的提升，单机 MySQL 出现危机：
我们在考虑MySQL数据库的高可用的架构时，如果数据库发生了宕机或者意外中断等故障，能尽快恢复数据库的可用性，尽可能的减少停机时间，保证业务不会因为数据库的故障而中断。与此同时，用作备份、只读副本等功能的非主节点的数据应该和主节点的数据实时或者最终保持一致。当业务发生数据库切换时，切换前后的数据库内容应当一致，不会因为数据缺失或者数据不一致而影响业务。这些都是MySQL高可用方案的基本标准。
Windows故障转移群集是由多个服务器组成的共同提供某高可用服务，该服务用于防止单台服务器故障导致服务失效。故障转移群集是一种高可用性的基础结构层，由多台计算机组成，每台计算机相当于一个冗余节点，整个群集系统允许某部分节点掉线、故障或损坏而不影响整个系统的正常运作。一台服务器接管发生故障的服务器的过程通常称为"故障转移"。
当一个Web系统从日访问量10万逐步增长到1000万，甚至超过1亿的过程中，Web系统承受的压力会越来越大，在这个过程中，我们会遇到很多的问题。为了解决这些性能压力带来问题，我们需要在Web系统架构层
Redis 的复制功能分为同步( sync )和命令传播( command propagate )两个步骤：
关于对高可用的分级在这里我们不做详细的讨论，这里只讨论常用高可用方案的优缺点以及高可用方案的选型。
随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，每天百万级甚至上亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。
本人转载：http://www.cnblogs.com/ejiyuan/archive/2010/10/29/1796292.html
当一个Web系统从日访问量10万逐步增长到1000万，甚至超过1亿的过程中，Web系统承受的压力会越来越大，在这个过程中，我们会遇到很多的问题。为了解决这些性能压力带来问题，我们需要在Web系统架构层面搭建多个层次的缓存机制。在不同的压力阶段，我们会遇到不同的问题，通过搭建不同的服务和架构来解决。
领取专属 10元无门槛券
手把手带您无忧上云
