数据库集群

数据库的锁：高并发导致的问题。解决的原理是？ ==================代码的锁解决的一般是 更新丢失 的问题，这个问题在数据库是不存在的，数据库最低的隔离级别也能满足这一点。 （所以数据库也不存在数据相同的两个写库的集群方式，数据库性能瓶颈的解决方式是读写分离，或者分表分库来扩展。更像微服务的扩展方式，而不是简单的增加集群。 这也是应用层和数据层的区别 ）============ 代码高并发时加锁：全局变量+高并发导致的问题。 分布式锁：高并发+集群导致的问题。 延伸： 分布式事务、CAP、强一致性、弱一致性、最终一致性。 幂等（多次调用只执行一次，目的也是数据一致性）、CAS（乐观锁只是一个概念） 分布式锁。 这些都是分布式或者集群导致的问题。 解决方案： 。。。。。 来源： https://www.cnblogs.com/cuiqq/p/12004132.html

java处理高并发高负载类网站中数据库的设计方法（java教程,java处理大量数据，java高负载数据） 一：高并发高负载类网站关注点之数据库 没错,首先是数据库,这是大多数应用所面临的首个SPOF。尤其是Web2.0的应用，数据库的响应是首先要解决的。 一般来说MySQL是最常用的，可能最初是一个mysql主机，当数据增加到100万以上，那么，MySQL的效能急剧下降。常用的优化措施是M-S（主-从）方式进行同步复制，将查询和操作和分别在不同的服务器上进行操作。我推荐的是M-M-Slaves方式，2个主Mysql，多个Slaves，需要注意的是，虽然有2个Master，但是同时只有1个是Active，我们可以在一定时候切换。之所以用2个M，是保证M不会又成为系统的SPOF。 Slaves可以进一步负载均衡，可以结合LVS,从而将select操作适当的平衡到不同的slaves上。 以上架构可以抗衡到一定量的负载，但是随着用户进一步增加，你的用户表数据超过1千万，这时那个M变成了SPOF。你不能任意扩充Slaves，否则复制同步的开销将直线上升，怎么办？我的方法是表分区，从业务层面上进行分区。最简单的，以用户数据为例。根据一定的切分方式，比如id，切分到不同的数据库集群去。 全局数据库用于meta数据的查询。缺点是每次查询，会增加一次，比如你要查一个用户nightsailer

RAC----real application cluster 10g----clusterware 11g----包含在grid软件中 集群支持的文件系统： 集权文件系统 ocfs asm rac--集中管理内存，cpu 数据库服务器没有办法满足需求：----通过rac进行集中管理 内存不够 cpu不够 硬盘不够 内网/私网---集群中节点与节点之间的网络连接，网络传输数率要求很高 需要网络交换机 全局SGA，管理每个SGA的信息，全局SGA由集群管理放在共享存储里 应用程序---外网（需要网卡）---连接数据库--一般给DBA用，有几个节点就需要几个IP地址 应用程序/用户使用（需要网卡）---虚拟网络/vip----如果有一个用户用外网联机到数据库，有一个节点失效了，我们就应用我们的集群软件虚拟出来的网络，进行我们实例的切换 需要配置tnsnames.ora，将节点信息写入到文件中 11g中 scan--简单客户端网络：简化用户在tnsnames的配置，scan中一共有3个地址，不是真实的网络。配置的时候主机名默认为racscan。使用racscan需要配置DNS服务器。 所有实例都访问一个数据库--多个实例向一个数据库写数据--数据库放到共享存储/共享文件系统中（orfs/acfs） 实例访问存储的网---需要存储网络，通过交换机，不能直连,做成主备保证时时都可访问

这篇文章很不错。对 数据库水平扩展技术的前因后果讲解得比较透。转载来与大家分享（原始出处我已经找不到了，应该是来自于阿里的同学们）。 ------------------------------------------ 1 引言 随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层已经成为架构研发人员首选的方式。水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了了宕机造成的损失。通过负载均衡策略，有效的降低了单台机器的访问负载，降低了宕机的可能性；通过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；通过读写分离策略更是最大限度了提高了应用中读取（Read）数据的速度和并发量。目前国内的大型互联网应用中，大量的采用了这样的数据切分方案，Taobao,Alibaba,Tencent，它们大都实现了自己的分布式数据访问层（DDAL）。以实现方式和实现的层次来划分，大概分为两个层次（Java应用为例）：JDBC层的封装，ORM框架层的实现。就JDBC层的直接封装而言，现在国内发展较好的一个项目是被称作“变形虫”(Amoeba)的项目，由阿里集团的研究院开发，现在仍然处于测试阶段（beta版）

Kubernetes 应用部署实战 2018-08-08 19:44:56 wuxiangping2017 阅读数 3084 收藏 更多 分类专栏： linux运维与架构师 简介 伙计们，请搬好小板凳坐好，下面将是一段漫长的旅程，期望你能够乐在其中。 我将基于 Kubernetes [1] 部署一个分布式应用。我曾试图编写一个尽可能真实的应用，但由于时间和精力有限，最终砍掉了很多细节。 我将聚焦 Kubernetes 及其部署。 让我们开始吧。 应用 TL;DR 该应用本身由 6 个组件构成。代码可以从如下链接中找到： Kubenetes 集群示例 [2]。 这是一个人脸识别服务，通过比较已知个人的图片，识别给定图片对应的个人。前端页面用表格形式简要的展示图片及对应的个人。具体而言，向 接收器 [3] 发送请求，请求包含指向一个图片的链接。图片可以位于任何位置。接受器将图片地址存储到数据库 (MySQL) 中，然后向队列发送处理请求，请求中包含已保存图片的 ID。这里我们使用 NSQ [4] 建立队列。 图片处理 [5] 服务一直监听处理请求队列，从中获取任务。处理过程包括如下几步：获取图片 ID，读取图片，通过 gRPC [6] 将图片路径发送至 Python 编写的 人脸识别 [7] 后端。如果识别成功，后端给出图片对应个人的名字。图片处理器进而根据个人 ID 更新图片记录

1.背景 SequoiaDB 巨杉数据库是一款金融级分布式数据库，包括了分布式 NewSQL、分布式文件系统与对象存储、与高性能 NoSQL 三种存储模式，分别对应分布式在线交易、非结构化数据和内容管理、以及海量数据管理和高性能访问场景。 集群一般会使用三副本方式以确保数据安全。假若集群发生因硬件故障等原因导致的节点故障或集群异常，数据库管理员应进行系统的分析和诊断，以确保集群正常工作，不会影响用户的正常使用。本文将与大家分享一下基本的 SequoiaDB 数据库诊断方法。 2. 数据库集群诊断 1）确定 SequoiaDB 的安装路径 如果用户刚接触全新的 SequoiaDB 环境，可以通过 cat /etc/default/sequoiadb 命令查看数据库安装路径。 # cat tc/default/sequoiadb NAME=sdbcm SDBADMIN_USER=sdbadmin INSTALL_DIR=/opt/sequoiadb INSTALL_DIR即 SequoiaDB 的安装路径。 2）列出集群节点信息 【检查办法】 切换到数据库安装用户（默认为sdbadmin用户），查看节点信息和全部节点。 $ sdblist -l $ sdblist -t all 从左到右依次为SvcName（节点名称）、Role（角色名称分为：编目节点、协调节点和数节点）、PID

现实中redis需要若干台redis服务器的支持： （1）从结构上，单个Redis服务器会产生单点故障，同时一台服务器需要承受所有的请求负载。这就需要为数据生成多个副本并分配在不同的服务器上。 （2）从容量上，单个Redis服务器的内存非常容易成为存储瓶颈，所以需要进行数据分片。 同时拥有多个Redis服务器后就会面临如何管理集群的问题，包括如何增加节点，故障恢复等操作。 1. 复制 通过持久化功能，Redis保证了即使在服务器重启的情况下也不会损失(或少量损失)数据。 但是由于数据是存储在一台服务器上的，如果这台服务器出现硬盘故障等问题，也会导致数据丢失。为了避免单点故障，通常的做法是将数据库复制多个副本部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务。为此， Redis提供了复制(replication)功能，可以实现当一台服务器中的数据更新后，自动更新的数据同步到其他数据库上 。 2. 哨兵 在一个典型的一主多从的Redis系统中，从数据库在整个系统中起到了数据冗余备份和读写分离的作用。当主数据库遇到异常中断服务后，开发者可以通过手动的方式选择一个从数据库升级为主数据库，以使得系统能够继续提供服务。然而整个过程相对麻烦且需要人工介入，难以实现自动化。为此， Redis2.8中提供了哨兵工具来实现自动的系统监控和故障恢复功能 。 3. 集群：

1、下载安装 二进制下载： https://github.com/coreos/etcd/releases/download/v3.3.13/etcd-v3.3.13-linux-amd64.tar.gz 1 [root@k8s-master01 ~]# tar xf etcd-v3.3.13-linux-amd64.tar.gz 2 [root@k8s-master01 ~]# cd etcd-v3.3.13-linux-amd64 3 [root@k8s-master01 etcd-v3.3.13-linux-amd64]# ll 4 总用量 29776 5 drwxr-xr-x 10 1000 1000 4096 5月 3 2019 Documentation 6 -rwxr-xr-x 1 1000 1000 16927136 5月 3 2019 etcd 7 -rwxr-xr-x 1 1000 1000 13498880 5月 3 2019 etcdctl 8 -rw-r--r-- 1 1000 1000 38864 5月 3 2019 README-etcdctl.md 9 -rw-r--r-- 1 1000 1000 7262 5月 3 2019 README.md 10 -rw-r--r-- 1 1000 1000 7855 5月 3 2019 READMEv2

7. Redis持久化有哪几种方式？不同的持久化机制都有什么优缺点？持久化机制具体底层是如何实现的？ 为什么要持久化？ 如果只是存在内存里，如果redis宕机再重启，内存数据就丢失了，所以要用持久化机制。 将数据写入内存的同时，异步的慢慢将数据写入磁盘文件，定期同步或备份到云存储服务上，进行持久化。 如果redis宕机重启，自动从磁盘加载之前持久化的一些数据，也许会丢失少量数据，但至少不会丢所有数据。 Redis 持久化的两种方式: RDB 和 AOF RDB(Redis Database) : 是对redis中的数据执行 周期性 的持久化。 简单说就是每个几分钟或几个小时，生成redis内存中数据的一份全量快照副本。 AOF(Append-Only-File) ：是对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集。 现在操作系统中，写文件不是直接写磁盘，会先写os cache(linux)，然后到一定时间从os cache写到磁盘文件。 如果同时使用 RDB 和 AOF 两种持久化机制，那么在 redis 重启的时候，会使用 AOF 来重新构建数据，因为 AOF 中的数据更加完整。 RDB 优缺点： 优点： 1. 非常适合做冷备份。 RDB生成多个文件

#何为大型网站# ##大型网站特性## 既然说的是大型网站架构，那么 架构的背后自然是解决人因面对大型网站特性而带来的问题 。这样可以先给大家说下大型网站的特性， 这些特性带来的问题就是人要解决的问题 ： 高并发、大流量：PV 量巨大； 高可用：7*24 小时不间断服务； 海量数据：文件数目分分钟 xxTB； 用户分布广泛，网络情况复杂：网络运营商； 安全环境恶劣：黑客的攻击； 需求快速变更，发布频繁：快速适应市场，满足用户需求； 渐进式发展：慢慢地运营出大型网站； ##大型网站目标## 既然说到了大型网站的特性，那么**解决这些特性带来的问题要达到什么目标呢？**如下： 每个目标背后面临着技术、设计、维护等诸多方面的挑战； 而目标本身的期望值也会根据实际情况进行调整，这也意味着网站架构建设是个不断调整的过程。 有了问题，也定了伟大的目标，那么网站在不同阶段面对不同的问题，是如何解决的？又是如何一步步成长为大型网站架构，实现这些伟大的目标呢？ ##如何网站架构## 首先，什么是大型网站架构呢？ 其实大型网站架构的概念对于每一个开发者来说很笼统、很模糊，正如盲人摸象，看到的、了解到的只是很小的一部分，大部分情况下我们只是负责架构中的一小块内容，所以很难清晰地给出具体定义。这就是所谓“不识庐山真面目 只缘身在此山中”的尴尬吧。所以我们要跳出来，站在宏观的角度