快照技术

maven快照版本和发布版本区别 转自 https://www.cnblogs.com/wuchanming/p/5484091.html 在使用maven过程中，我们在开发阶段经常性的会有很多公共库处于不稳定状态，随时需要修改并发布，可能一天就要发布一次，遇到bug时，甚至一天要发布N次。我们知道，maven的依赖管理是基于版本管理的，对于发布状态的artifact，如果版本号相同，即使我们内部的镜像服务器上的组件比本地新，maven也不会主动下载的。如果我们在开发阶段都是基于正式发布版本来做依赖管理，那么遇到这个问题，就需要升级组件的版本号，可这样就明显不符合要求和实际情况了。但是，如果是基于快照版本，那么问题就自热而然的解决了，而maven已经为我们准备好了这一切。 maven中的仓库分为两种，snapshot快照仓库和release发布仓库。snapshot快照仓库用于保存开发过程中的不稳定版本，release正式仓库则是用来保存稳定的发行版本。定义一个组件/模块为快照版本，只需要在pom文件中在该模块的版本号后加上 -SNAPSHOT 即可(注意这里必须是大写)，如下： <groupId>cc.mzone</groupId> <artifactId>m1</artifactId> <version>0.1-SNAPSHOT</version> <packaging>jar

1、什么是Redis redis本质是一个key-value类型的内存数据库，整个数据库统统加载在内存中进行操作，定期通过异步操作把数据库数据flush到硬盘上保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。除此之外，redis还支持多种数据结构(如list,string,set,zset,hash)。 2、Redis为什么这么快？ ①、redis完全基于内存 ②、使用单线程，避免了不必要的上下文切换和竞争条件 ③、使用了I/O多路复用模型 关于redis I/O多路复用解释如下图： 这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），且 Redis 在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈，主要由以上几点造就了 Redis 具有很高的吞吐量。 3、为什么Redis是单线程的？ 对于Redis的单线程解释：单线程指的是网络请求模块使用了一个线程（所以不需考虑并发安全性），即一个线程处理所有网络请求，其他模块仍用了多个线程。 官方FAQ表示，因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽

LVM逻辑卷管理器 LVM可以允许用户对硬盘资源进行动态调整。 部署逻辑卷 部署LVM时，需要逐个配置物理卷、卷组和逻辑卷。 (PV操作->VG操作->LV操作) 部署逻辑卷 注意切割单位的问题。在对逻辑卷进行切割时有两种计量单位。第一种是以容量为单位，所使用的参数为-L。 另外一种是以基本单元的个数为单位，所使用的参数为-l。 逻辑卷快照 LVM的快照卷功能有两个特点： 快照卷的容量必须等同于逻辑卷的容量； 快照卷仅一次有效，一旦执行还原操作后则会被立即自动删除。 来源： 51CTO 作者： 盏茶浅抿xie 链接： https://blog.51cto.com/14606977/2455055

摘 要 孔子云：工欲善其事，必先利其器。作为开发人员，我们致力于为最终用户实现工作流程自动化；然而，许多开发人员却疏忽了将自己的开发流程自动化。企业级应用系统涉及到开发、测试、部署、实施等一系列开发流程，在整个软件开发过程中我们如何借助工具、方法和模式使过程简单自动化，减少一些低效繁琐的开发工作量。 本系列试图使用一系列的工具介绍帮助大家在日常工作中减轻繁杂低效的开发工作，借助于现有的一系列工具提升大家的开发效率，使大家日常工作做到事半功倍。 在 Java 程序的开发过程中，不可避免地会遇到内存使用、性能瓶颈等问题。 Java Profiler 工具能帮助开发人员快速、有效地定位这些问题，因此成为了 Java 开发过程中的一个重要工具 。 本文作为该系列的第二章，介绍Java EE应用的系统性能监控工具JProfiler，JProfiler 可以通过时时的监控系统的内存使用情况，随时监视垃圾回收，线程运行状况等手段，从而很好的监视 JVM 运行情况及其性能。 通过介绍这个工具的使用，帮助开发人员发现系统应用的性能瓶颈，提升系统运行性能。 一、 JProfiler 是什么？ JProfiler 是一个全功能的 Java 剖析工具（ profiler ），专用于分析 J2SE 和 J2EE 应用程序。它把 CPU 、执行绪和内存的剖析组合在一个强大的应用中。 JProfiler

SOFAStack （ S calable O pen F inancial A rchitecture Stack）是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现，支持 MULTI-RAFT-GROUP，适用于高负载低延迟的场景。 本文为《剖析 | SOFAJRaft 实现原理》最后一篇，本篇作者胡宗棠，来自中国移动。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品，项目代号： SOFA:JRaftLab/ ，文末包含往期系列文章。 SOFAJRaft： https://gitee.com/sofastack/sofa-jraft 导读 本文主要介绍 SOFAJRaft 在日志复制和管理中所采用的快照机制。考虑到单独介绍 SOFAJRaft 中的快照机制原理和实现或许有一些唐突，我会先通过一个读者都能够看得明白的例子作为切入点，让大家对快照这个概念、它可以解决的主要问题，先有一个比较深刻的理解。 一、快照的概念与特点 SOFAJRaft 是对 Raft 共识算法的 Java 实现。既然是共识算法，就不可避免的要对需要达成共识的内容，在多个服务器节点之间进行传输，一般将这些共识的内容称之为日志块

1.Cache引起的数据一致性问题 　　主要原因是位于数据IO路径上的各种Cache和Buffer（包括数据块Cache，文件系统的Cache，存储控制器的Cache，磁盘Cache等），由于不同系统模块操作处理数据IO的速度有差异，所以就需要添加Cache来缓存IO操作，适配不同模块的处理速度。这些Cache在提高系统处理性能的同时，也可能会‘滞留’IO操作，带来一些负面影响。如果在系统发生故障时，仍有部分IO‘滞留’在IO操作中，真正写到磁盘中的数据就会少于应用程序实际写出的数据，造成的数据不一致。当系统恢复时，直接从硬盘中读出的数据可能存在逻辑错误，导致应用无法启动。尽管一些数据库（Oracle，DB2）可以根据redo日志重新生成数据，修复逻辑错误，单着过程是非常耗时的，而且也不一定每次都能成功。对于一些相对功能较弱的数据库（SQL Server），这个问题就更加严重了。 　　解决办法 　　关闭Cache或者创建快照。尽管关闭Cache会导致系统系统性能下降，但在有些应用中，这却是必要的选择 。比如一些高等级的容灾方案中（ RPO 为 0 ），都是利用同步镜像技术在生产中心和灾备中心之间实时同步复制数据。由于数据是实时复制的，所以就必须要关闭 Cache 。 　　快照的目的是为数据卷创建一个在特定时间点的状态视图，通过这个视图只可以看到数据卷在创建时刻的数据

由于数据存储期间，可能发生错误、故障的点特别多，比如网络中断、磁盘写满等，面对这些复杂的情况，应用层应付起来非常困难。所以就有了事务的概念，说道事务，我们最先能想到的就是：可以一次事务中将很多读写入操作打包成一个逻辑操作单元，整个事务不成功（Committed）便成仁（Rollback）。如果失败，应用层可根据情况安全地重试，不用担心部分写入的问题。 总的来说，事务就是一层抽象，为简化应用层编程模型而生！当然，并非所有的数据库都支持事务，但是对关系型数据库而言，这个基本是标配；某些 NoSQL 数据库可能因为性能、可用性以及扩展性考虑，而放弃了对事务的支持。另外，分布式数据库下，事务的实现会更加困难，并且执行开销也很大，但并不代表它不能实现。典型的 分布式关系数据库如 TiDB 以及 Google Spanner 就提供了事务支持。 深入理解 ACID Atomicity（原子性） ：将多个写操作纳入一个原子事务中，并在故障（进程崩溃、网络中断、磁盘故障）发生时能够及时中止事务，并将部分完成的写入全部丢弃。 Consistency（一致性） ： 对数据有特定的状态预期，任何数据变更必须满足这些状态约束（或者恒等条件） 应用进程应该负责保证这种一致性，数据库只是存储 这个更多的是应用层属性 ，所以 C 原本不属于 ACID，只是作者 Joe Hellerstein

1：什么是云计算？ 云计算是一种按量付费的模式！云计算的底层是通过虚拟化技术来实现的！ 2：云计算的服务类型 2.1 IAAS基础设施即服务（基础设施即服务）虚拟机 ecs openstack 2.2 PAAS平台即服务（平台即服务）php，java docker容器 2.3 SAAS软件即服务 企业邮箱服务cdn服务 rds数据库 开发+运维 3：为什么要用云计算 小公司：10台20w + idc 5w + 100M 10W，10台云主机，前期投入小，扩展灵活，风险小 大公司：闲置服务器计算资源，虚拟机，出租（超卖） 64G服务器64台1G 320台1G 64台大公司自己的业务264台租出去 国企，银行 4：云计算的基础KVM虚拟化 主机：内存4G +纯净的系统CentOS-7 4.1：什么是虚拟化？ 虚拟化，通过模拟计算机的硬件，来实现在同一台计算机上同时运行多个不同的操作系统的技术。 4.2：虚拟化软件的差异 linux虚拟化软件：qemu软件纯模拟全虚拟化软件，特别慢！AIX，兼容性好！ xen（半）性能特别好，需要使用专门修改之后的内核，兼容性差！ redhat 5.5 xen kvm KVM（Linux）全虚拟机，它有硬件支持cpu，基于内核，而且不需要使用专门的内核centos6 kvm性能更好，兼容更好 vmware工作站：图形界面 虚拟框：图形界面Oracle 4

ceph概述 基础知识 什么是分布式文件系统 • 分布式文件系统 (Distributed File System) 是指文件系统管理的物理存储资源不一定 直接连接在本地节点上 , 而是通过计算机网络与节点相连 • 分布式文件系统的设计基于客户机 / 服务器模式 常用分布式文件系统 • Lustre • Hadoop • FastDFS • Ceph • GlusterFS 什么是 ceph • ceph 是一个分布式文件系统 • 具有高扩展、高可用、高性能的特点 • ceph 可以提供对象存储、块存储、文件系统存储 • ceph 可以提供 PB 级别的存储空间 (PBàTBàGB) – 1024G*1024G=1048576G • 软件定义存储 (Software Defined Storage) 作为存储行业的一大发展趋势 , 已经越来越 受到市场的认 ceph 组件 OSDs ：存储设备， ceph 对象存储设备，它是唯一的真正存储数据的设备，只由 OSD 存储设备，它是一个进程，一般来说 OSD 关联到集群中的每块物理硬盘，所以集群中由多少块硬盘就有多少个 OSD 进程 Monitors （ MON ）：集群监控组件， ceph 通过一系列的映射表来监控集群状态，一般来说 MON 是奇数个 MDSs ：存放文件系统的元数据服务器 ( 对象存储和块存储不需要该组件 )

安装一个 KVM服务器 案例 1 ：安装一个 KVM 服务器 案例 2 ： KVM 平台构建及简单管理 案例 3 ： virsh 基本管理操作 案例 4 ： xml 配置文件的应用 案例 5 ：为虚拟机制作快照备份 案例 6 ：快建新虚拟机 1 案例 1 ：安装一个 KVM 服务器 1.1 问题 本例要求准备一台 RHEL7.2 服务器，将其搭建为 KVM 平台，主要完成下列操作： 关闭本机的 SELinux 保护、防火墙服务 挂载 RHEL7 光盘到 /mnt/dvd ，将其配置为本机 YUM 源（ baseurl=file:///mnt/dvd ） 安装 KVM 相关包组，确保已启用 libvirtd 服务 1.2 方案 RHEL7 中的虚拟化服务软件组： 虚拟化平台 ——"Virtualization Platform" 虚拟化主机 ——"Virtualization Host" 虚拟化客户端 ——"Virtualization Client" 另外需要注意， yum 命令的软件组管理操作与 RHEL6 有些小变化： yum groups list[hidden][ 组名 ]... yum groups info[ 组名 ]... yum groups install[ 组名 ]... yum groups remove[ 组名 ]... 1.3 步骤