日志分析系统
Windows系统中的系统日志查看与分析
Windows系统中的系统日志查看与分析Windows操作系统提供了一个系统日志功能，用于记录操作系统和应用程序的活动和事件。
系统日志是管理员和技术支持人员用来诊断系统问题和监视系统性能的重要工具。
本文将介绍在Windows系统中如何查看和分析系统日志。
一、查看系统日志在Windows系统中，可以通过事件查看器来查看系统日志。
以下是查看系统日志的方法：1. 打开事件查看器在Windows操作系统的开始菜单中，搜索并打开“事件查看器”。
2. 导航至系统日志在事件查看器左侧的导航栏中，展开“Windows日志”，然后选择“系统”。
3. 检查日志系统日志中列出了操作系统的各种事件和错误。
可以根据事件级别（如错误、警告、信息）和日期范围进行筛选和排序。
二、分析系统日志系统日志中的事件提供了有关系统的重要信息和警告。
以下是分析系统日志的一些常见方法：1. 查找错误和警告在系统日志中，查找错误（红色叉号）和警告（黄色感叹号）的事件。
这些事件表示可能存在的问题或潜在的系统错误。
2. 查看事件详细信息双击一个事件，以查看其详细信息。
可以获得有关事件的时间戳、源、类别和描述等信息。
此外，还可以查看事件的特定属性和数据。
3. 使用筛选器事件查看器提供了筛选器功能，可以根据关键字、事件ID和事件级别等条件来筛选事件。
这有助于快速找到与特定问题相关的事件。
4. 导出日志有时，需要将系统日志导出并共享给其他技术支持人员。
可以使用事件查看器的导出功能将日志保存为文件，供后续分析和分享。
三、常见的系统日志事件以下是一些常见的系统日志事件及其含义：1. 硬件故障事件这些事件通常与硬件设备（如磁盘驱动器、内存）有关，表示硬件故障或错误。
2. 系统错误事件这些事件表示操作系统遇到了错误或异常情况。
例如，系统崩溃、蓝屏或无响应等。
3. 应用程序错误事件这些事件与特定应用程序有关，表示应用程序遇到了错误或异常情况。
4. 安全事件安全事件包括登录失败、文件访问权限等与系统安全相关的事件。
日志分析系统
日志分析系统日志分析系统的重要性和应用当今数字时代，数据量呈现爆发式增长，企业在日常运营过程中产生了大量的日志数据。
这些日志数据蕴含着宝贵的信息，通过对这些数据进行分析和挖掘，企业可以获得深入洞察和有价值的见解，从而优化运营策略，并做出更明智的决策。
为了实现对日志数据的高效分析和应用，日志分析系统应运而生。
日志分析系统是一种用于收集、存储、分析和展示日志数据的工具。
它能够自动化地对日志数据进行处理和解析，并将其转化为可读性和易理解性较强的格式。
通过对日志数据进行统计、查询和分析，日志分析系统能有效地发现和解决潜在问题，帮助企业提升效率、降低风险以及优化用户体验。
日志分析系统的应用领域非常广泛。
首先，它在电子商务行业中扮演着重要的角色。
电子商务平台每天都会收集大量的用户操作日志，通过对这些日志数据进行分析，企业可以了解用户的行为习惯和购买偏好，进而个性化推荐产品和优化用户界面，提升用户体验和满意度。
另外，日志分析系统在网络安全领域也起到了关键的作用。
网络攻击和入侵事件日益猖獗，为了保护企业的网络安全，日志分析系统可以对网络流量数据进行实时监控和分析，及时发现可疑的活动和异常行为，并采取相应的防御措施，保护企业的信息和资产安全。
此外，在软件开发和运维领域，日志分析系统也发挥着重要的作用。
软件系统的稳定性和性能对于企业的正常运营至关重要，通过对系统日志数据进行监控和分析，可以及时发现和定位潜在的问题，并加以解决，保证系统的稳定性和正常运行。
随着云计算和大数据技术的不断发展，日志分析系统也在不断演进和创新。
传统的日志分析系统主要通过批处理的方式进行数据处理和分析，效率和响应速度相对较低。
而现在，借助云计算和大数据技术的应用，日志分析系统可以实现实时处理和分析，大大提高了系统的性能和响应速度。
总之，日志分析系统在当今数字化时代的企业运营中扮演着重要的角色。
它能够帮助企业挖掘隐藏在海量日志数据中的有价值信息，从而优化运营策略、提升用户体验和保护信息安全。
日志分析系统范文
日志分析系统范文日志分析系统是一种能够收集、存储和分析各种系统和应用程序所产生的日志数据的软件系统。
它可以帮助企业和组织实时监控系统运行状态、发现问题和故障、提供数据分析和决策支持等功能。
本文将从日志分析系统的背景、功能、架构和应用领域等方面进行详细介绍。
一、背景随着信息技术的迅猛发展，企业和组织所面对的信息量越来越大，各种系统和应用程序也越来越复杂，因此，日志分析变得愈发重要。
通过对各种系统和应用程序所产生的日志数据进行分析，可以帮助企业和组织实时监控系统运行状态、发现问题和故障、提供数据分析和决策支持等。
二、功能1.日志收集：日志分析系统能够自动收集各种系统和应用程序所产生的日志数据，并存储在中央数据库中，方便后续的分析和查询。
2.日志存储：日志分析系统通过各种技术手段，如数据库、分布式文件系统等，将大量的日志数据进行存储和管理，以确保数据的可靠性和容错性。
3.日志分析：日志分析系统通过各种算法和模型，对收集到的日志数据进行分析，提取其中的有价值信息，如异常事件、用户行为模式、系统性能指标等。
4.实时监控：日志分析系统能够实时监控系统运行状态，通过预设的规则和阈值，发现问题和故障，并及时向相关人员发送报警通知。
5.数据可视化：日志分析系统能够将分析结果以图形化或表格化的方式展示，方便用户直观地理解和分析数据。
6.自动化报告：日志分析系统能够自动生成各种报告和分析结果，支持自定义报表和定时报表的生成，方便用户进行数据分析和决策支持。
三、架构1.日志采集器：负责收集各种系统和应用程序产生的日志数据，并将其发送到中央服务器进行存储和分析。
2.中央服务器：负责接收和存储日志数据，提供数据的存储和查询功能，并提供分析引擎进行数据分析。
3.数据库：用于存储日志数据，提供高速读写和可靠性保证的数据存储引擎。
4.分析引擎：负责对日志数据进行分析，通过各种算法和模型提取有价值的信息，并生成报告和分析结果。
5.可视化界面：用于展示分析结果和报告，支持图形化和表格化方式展示数据，方便用户进行数据分析和决策支持。
Windows系统系统日志分析技巧解读系统错误和警告
Windows系统系统日志分析技巧解读系统错误和警告Windows操作系统是目前世界上最常用的操作系统之一，它的稳定性和可靠性备受用户赞赏。
然而，就像任何其他复杂的软件系统一样，Windows也可能出现错误和警告。
为了帮助用户追踪和解决这些问题，Windows提供了系统日志功能。
系统日志是Windows系统中的一项关键功能，记录了系统中发生的各种事件和错误。
通过分析系统日志，用户可以获得有关系统问题的详细信息，并采取相应的措施来修复错误或解决潜在问题。
在本文中，我们将介绍一些分析系统日志的技巧，以帮助用户更好地理解和解读系统错误和警告。
1. 理解系统日志的基本原理系统日志是Windows操作系统的一个核心组件，它负责记录各种事件和错误信息。
系统日志的主要分类包括应用程序、安全性、系统和安全浏览。
每个日志都包含了各自的事件类型，如错误、警告和信息。
对于系统错误和警告的分析，我们需重点关注系统日志中的系统和应用程序事件。
2. 分析系统错误事件系统错误事件是指Windows系统内部发生的严重错误，这些错误通常会导致系统的功能异常或崩溃。
在系统日志中，系统错误事件以红色或黄色的标识出来，用户可以通过以下步骤进行分析：a. 打开事件查看器运行“eventvwr.msc”命令或通过控制面板中的“管理工具”打开事件查看器。
b. 导航到系统日志在事件查看器中，选择“Windows日志”下的“系统”。
c. 过滤系统错误事件在系统日志中，使用筛选功能过滤出系统错误事件。
常见的错误事件类型包括“Kernel-Power”、“BugCheck”和“Disk”。
d. 查看错误详情单击特定错误事件并查看其详细信息，包括错误代码、描述和相关进程信息等。
e. 尝试解决方案根据错误信息，尝试采取相应的措施来解决问题。
这可能包括更新驱动程序、修复操作系统或删除冲突的软件等。
3. 解读系统警告事件系统警告事件是指Windows系统中发生的一些非致命错误或潜在问题的警告信号。
天融信日志收集与分析系统
天融信日志收集与分析系统简介天融信日志收集与分析系统是一种用于收集、存储和分析大规模网络设备日志的系统。
该系统使用天融信开发的日志收集代理，能够自动采集分布在网络设备上的日志信息，并将其存储到中央数据库中。
用户可以通过界面进行查询和分析，从而快速发现潜在的安全威胁和网络问题。
功能特点1. 日志收集天融信日志收集与分析系统通过部署在网络设备上的日志收集代理，能够自动采集设备产生的各类日志。
代理会将采集到的日志按照配置的规则进行分类、过滤和标准化，然后将其发送到中央服务器进行存储和分析。
2. 大规模存储中央服务器使用分布式数据库来存储大规模的日志数据。
系统支持水平扩展，可以根据需求添加更多的存储节点，以适应不断增长的日志量。
3. 实时查询用户可以通过界面进行实时查询，根据关键词和时间范围过滤日志数据。
系统会快速返回匹配的结果，并提供友好的界面进行展示和导出。
4. 数据分析系统支持基于日志数据的数据分析，提供多种统计和图表展示功能。
用户可以利用这些功能，深入分析日志数据，发现网络问题、安全事件和异常行为。
5. 安全告警系统可以根据用户定义的规则进行实时监测，一旦发现异常事件，会自动触发告警机制。
用户可以通过界面配置告警规则，并接收告警通知，从而及时响应和处理安全威胁。
部署架构天融信日志收集与分析系统的架构主要包括以下几个组件：1. 日志采集代理日志采集代理部署在网络设备上，负责实时采集设备产生的日志。
采集代理会将采集到的日志按照预定义的规则进行处理，然后发送到中央服务器。
2. 中央服务器中央服务器负责接收、存储和分析采集到的日志数据。
服务器使用分布式数据库来存储海量的日志数据，并提供实时查询和分析功能。
3. 用户界面用户界面是用户与系统交互的界面，通过界面用户可以进行日志查询、分析、配置告警规则等操作。
界面友好易用，用户可以根据需求自定义查询条件和展示方式。
使用流程使用天融信日志收集与分析系统的流程如下：1.部署日志采集代理到网络设备上。
日志采集与分析系统
日志采集与分析系统日志采集与分析是一项重要的任务，它可以帮助我们监控系统的运行状况，分析和解决问题，优化系统性能，并且对于安全性管理也有着重要的作用。
下面我将详细介绍日志采集与分析系统的概念、实现方法以及其在实际应用中的意义。
一、日志采集与分析系统的概念日志采集与分析系统是指一种能够自动收集系统、应用程序和网络设备产生的日志信息，并对其进行分析、统计和展示的系统。
它的主要功能包括：收集来自不同系统的日志数据，存储日志数据，处理和分析日志数据以检测异常和问题，以及生成报告和可视化展示。
二、日志采集与分析系统的实现方法1.日志收集日志收集是系统的第一步，可以通过以下几种方式进行：（1）直接调用API：在应用程序中调用API来将日志数据直接发送给日志收集器。
（2）使用日志收集器：安装和配置日志收集器来自动收集日志信息。
（3）使用中间件：对于分布式系统，可以使用消息中间件来收集日志信息。
2.日志存储日志存储是为了方便后续的分析和查询，通常采用以下几种方式：（1）本地文件存储：将日志存储在本地文件中，可以按照时间或大小进行切分和归档。
（2）数据库存储：将日志存储在数据库中，方便查询和分析。
（3）云存储：将日志存储在云平台上，如AWSS3、阿里云OSS等，可以方便地进行可视化展示和分析。
3.日志处理与分析日志处理与分析是对日志数据进行解析、过滤和分析的过程，以检测异常和问题，并获取有价值的信息。
常用的方法包括：（1）日志解析：对日志进行解析，提取关键信息，如事件发生时间、事件类型、事件数据等。
（2）日志过滤：根据预设规则或条件来过滤日志，只保留关键和有价值的日志数据。
（3）日志分析：基于统计、机器学习或规则引擎等方法来进行日志数据的分析，以检测异常和问题。
4.可视化展示与报告生成通过可视化展示和报告生成，可以直观地了解系统的运行状况、异常和性能瓶颈，以及采取相应的措施。
通常有以下几种方式：（1）图表展示：以柱状图、折线图、饼图等形式展示系统的日志数据，如事件发生次数、占比等。
ELK日志分析系统
ELK⽇志分析系统⼀、ELK 概述1、ELK简介 ELK平台是⼀套完整的⽇志集中处理解决⽅案，将 ElasticSearch、Logstash 和 Kiabana 三个开源⼯具配合使⽤，完成更强⼤的⽤户对⽇志的查询、排序、统计需求。
ElasticSearch：是基于Lucene（⼀个全⽂检索引擎的架构）开发的分布式存储检索引擎，⽤来存储各类⽇志。
Elasticsearch 是⽤ Java 开发的，可通过 RESTful Web 接⼝，让⽤户可以通过浏览器与 Elasticsearch 通信。
Elasticsearch 是个分布式搜索和分析引擎，优点是能对⼤容量的数据进⾏接近实时的存储、搜索和分析操作。
Logstash：作为数据收集引擎。
它⽀持动态的从各种数据源搜集数据，并对数据进⾏过滤、分析、丰富、统⼀格式等操作，然后存储到⽤户指定的位置,⼀般会发送给 Elasticsearch。
Logstash 由JRuby 语⾔编写，运⾏在 Java 虚拟机（JVM）上，是⼀款强⼤的数据处理⼯具，可以实现数据传输、格式处理、格式化输出。
Logstash 具有强⼤的插件功能，常⽤于⽇志处理。
Kiabana：是基于 Node.js 开发的展⽰⼯具，可以为 Logstash 和 ElasticSearch 提供图形化的⽇志分析 Web 界⾯展⽰，可以汇总、分析和搜索重要数据⽇志。
Filebeat：轻量级的开源⽇志⽂件数据搜集器。
通常在需要采集数据的客户端安装 Filebeat，并指定⽬录与⽇志格式，Filebeat 就能快速收集数据，并发送给 logstash 进⾏解析，或是直接发给 Elasticsearch 存储，性能上相⽐运⾏于 JVM 上的 logstash 优势明显，是对它的替代。
2、为什么要使⽤ ELK ⽇志主要包括系统⽇志、应⽤程序⽇志和安全⽇志。
系统运维和开发⼈员可以通过⽇志了解服务器软硬件信息、检查配置过程中的错误及错误发⽣的原因。
ELK日志分析系统
ELK日志分析系统ELK日志分析系统是一种常用的开源日志管理和分析平台。
它由三个主要组件组成，即Elasticsearch、Logstash和Kibana，分别用于收集、存储、分析和可视化日志数据。
本文将介绍ELK日志分析系统的原理、特点和应用场景等。
ELK日志分析系统具有以下几个特点。
首先，它是一个开源系统，用户可以自由获取、使用和修改代码，满足各种定制化需求。
其次，它具有高度的可扩展性和灵活性，可以处理海量的日志数据，并支持实时查询和分析。
再次，它采用分布式架构，可以部署在多台服务器上，实现高可用性和负载均衡。
最后，它提供了丰富的可视化工具和功能，让用户可以直观地了解和分析日志数据，发现潜在的问题和异常。
ELK日志分析系统在各种场景下都有广泛的应用。
首先，它可以用于系统日志的监控和故障诊断。
通过收集和分析系统的日志数据，可以及时发现和解决问题，保证系统的正常运行。
其次，它可以用于应用程序的性能监控和优化。
通过分析应用程序的日志数据，可以找到性能瓶颈和潜在的问题，并采取相应的措施进行优化。
再次，它可以用于网络安全监控和威胁检测。
通过分析网络设备和服务器的日志数据，可以及时发现并应对潜在的安全威胁。
最后，它还可以用于业务数据分析和用户行为追踪。
通过分析用户的访问日志和行为日志，可以了解用户的偏好和行为模式，为业务决策提供依据。
然而，ELK日志分析系统也存在一些挑战和限制。
首先，对于大规模的日志数据，ELK系统需要消耗大量的存储和计算资源，对硬件设施和系统性能要求较高。
其次，ELK系统对日志的结构有一定的要求，如果日志数据过于复杂或不规范，可能会造成数据解析和处理的困难。
再次，ELK系统对于数据的实时性要求较高，以保证用户能够在短时间内获取到最新的数据和分析结果。
最后，对于非技术人员来说，ELK系统的配置和使用可能较为复杂，需要一定的培训和专业知识。
总之，ELK日志分析系统是一种功能强大且灵活的日志管理和分析工具，可以帮助用户实现日志数据的收集、存储、分析和可视化展示。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
日志分析系统
1.前言
随着江苏中烟信息化程度的不断提升，信息化系统的数目也不断增加，运维任务也不断增加。
为了应对日益增加的信息化需求，提升服务质量，减轻运维工作，在信息系统服务化的基础上，迫切需要一个管理平台，实现对所有服务的管理和监控，这就是微服务平台。
微服务平台能够实现devOps，服务的注册、发现、权限管理、监控、测试、故障预警，故障恢复等。
日志分析系统是微服务平台的重要组成部分，它能够对各服务的日志进行采集，存储，分析(找出异常的请求、统计报错情况、统计QPS、统计系统功能的使用情况、超负荷预警等)。
同时，对系统资源的监控信息也可以以日志的形式，由日志分析系统分析。
日志分析系统后台使用大数据平台来存储和分析日志，能够支持大量的日志，不需要担心日志的存储问题。
2.日志分析系统
2.1.功能
日志分析系统主要功能包括日志的采集、存储、分析。
日志采集常见的场景如：对webserver服务器的log文件进行监控，发现有变动时，采集变动的信息；对网络的某个端口监控，当此端口出现数据流时，采集数据流；监控程序定时的获取系统资源信息(同理，也适用于对JVM，tomcat的监控)；采集Http请求和响应(同理适用于rpc远程调用)。
日志的存储使用大数据平台。
根据日志的类型，可以以非结构化或者结构化数据存储，也可以使用图数据库存储。
日志分析包括日志的离线和在线分析。
离线分析借助大数据平台提供的SQL，对日志数据库中的所有数据进行统计分析，适合于统计QPS，系统功能使用情况。
在线分析(实时分析)处理即时产生的日志信息，适合于预警，异常请求的监控。
2.2.结构
3.实现
3.1.要求
✓能够适配不同的日志数据，例如web server log、rpc log、syslog
✓能够处理突发的大流量数据
✓能够检测日志系统的个节点的运行状态，并自动恢复
✓能够方便的和Hive、Spark、Hbase等集成
✓稳定的运行，尽量少占用资源
3.2.日志收集和路由
logstash是一种分布式日志收集框架，非常简洁强大，经常与ElasticSearch，Kibana配置，组成著名的ELK技术栈，非常适合用来做日志数据的分析。
Logstash分为Shipper（收集日志），Broker（日志集线器，可以连接多个Shipper），Indexer（日志存储）。
Shipper 支持多种类型的日志文件，且可以自定义插件支持更多的种类。
Logstash采用JRuby语言实现，插件开发相对困难。
Logstash可以通过配置正则表达式的方式，将日志解析为结构化数
据。
Broker一般使用Redis实现，Indexer一般将日志存储到EL search。
flume是分布式的日志收集系统，它将各个服务器中的数据收集起来并送到指定的地方去。
Flume分为source（数据源）、channel（数据通道和缓存）、sink。
Flume支持非常多种类的数据源，包括日志文件、tcp连接、thrift远程调用框架、netcat、定时程序等。
Flume 使用java语言开发，能够自定义source、channel、sink。
Channel支持file channel，memory channel，kafka channel，JDBC channel等。
Sink支持HDFS、Hive、Avro（发送到其他机器的某个端口）、File Roll Sink、Hbase Sink、ES Sink、Solr Sink、Kite Dataset Sink、kafka Sink、http Sink等（或者自定义Sink）。
3.3.方案
Flume(日志收集系统)+ kafka-channel(分布式消息队列) + Spark streaming Sink(消费者) 3.4.监控JVM
常见的监控方案
4.微服务协议比较
rest协议：
优点：
不容易被安全组件拦截
简单、规范、通用，所有语言都可以使用
debug方便，工具、资料非常多，支持很好
缺点：
性能没有rpc好
没有状态
rpc协议：
优点：
直接使用tcp协议，二进制序列化，效率高
同一种语言之间，调用方便
缺点：
工具支持少
有些框架不能跨语言
不能和网页端直接交互
建议：
(12月建议，后端服务使用grpc)人员、组织机构树、工作流服务、权限管理、数据字典、公共数据等可以使用rpc发布服务，业务提供的具体接口使用rest。
前端将这些整合在一起。
也就是说，以前办公系统common里面的代码通过远程调用的方式独立出去（数据也独立出去，重要），当common修改时，通过适配器或者字节码框架修改调用逻辑。
业务代码实现自己的逻辑，但是数据和common中的数据是完全分开的，只能通过接口传递数据（这个非常重要，是微服务的关键）。
前端可以根据情况，调用业务系统的接口。
5.问题
5.1.分布式事物
场景：A系统调用B的接口，A系统在调用过程中，需要修改A系统数据和B系统的数据，如何保证此过程的事务性？
5.1.1.两阶段提交
两阶段提交：
1)应用程序client发起一个请求到TC
2)TC先将<prepare>消息写到本地日志，之后向所有的Si发起<prepare>消息。
以支付
宝转账到余额宝为例，TC给A的prepare消息是通知支付宝数据库相应账目扣款1
万，TC给B的prepare消息是通知余额宝数据库相应账目增加1w。
为什么在执行
任务前需要先写本地日志，主要是为了故障后恢复用，本地日志起到现实生活中凭
证的效果，如果没有本地日志（凭证），出问题容易死无对证；
3)Si收到<prepare>消息后，执行具体本机事务，但不会进行commit，如果成功返回
<yes>，不成功返回<no>。
同理，返回前都应把要返回的消息写到日志里，当作凭
证。
4)TC收集所有执行器返回的消息，如果所有执行器都返回yes，那么给所有执行器发
生送commit消息，执行器收到commit后执行本地事务的commit操作；如果有任
一个执行器返回no，那么给所有执行器发送abort消息，执行器收到abort消息后
执行事务abort操作。
5.1.2.事务消息
1)支付宝在扣款事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录
消息数据，而不真正发送，只有消息发送成功后才会提交事务；
2)当支付宝扣款事务被提交成功后，向实时消息服务确认发送。
只有在得到确认发送
指令后，实时消息服务才真正发送该消息；
3)当支付宝扣款事务提交失败回滚后，向实时消息服务取消发送。
在得到取消发送指
令后，该消息将不会被发送；
4)对于那些未确认的消息或者取消的消息，需要有一个消息状态确认系统定时去支付
宝系统查询这个消息的状态并进行更新。
为什么需要这一步骤，举个例子：假设在
第2步支付宝扣款事务被成功提交后，系统挂了，此时消息状态并未被更新为“确
认发送”，从而导致消息不能被发送。
消息重复发送：解决方法很简单，在余额宝这边增加消息应用状态表（message_apply），通俗来说就是个账本，用于记录消息的消费情况，每次来一个消息，在真正执行之前，先去消息应用状态表中查询一遍，如果找到说明是重复消息，丢弃即可，如果没找到才执行，同时插入到消息应用状态表（同一事务）。
和TCC类似，Try的过程替换为发送事务消息，另外一个系统异步处理的且不会回滚，会重试多次，保证成功执行。
5.1.3.TCC事务补偿型
TCC在一个长事务（long-running ）中，一个由两台服务器一起参与的事务，服务器A发起事务，服务器B参与事务，B的事务需要人工参与，所以处理时间可能很长。
如果按照ACID的原则，要保持事务的隔离性、一致性，服务器A中发起的事务中使用到的事务资源将会被锁定，不允许其他应用访问到事务过程中的中间结果，直到整个事务被提交或者回滚。
这就造成事务A中的资源被长时间锁定，系统的可用性将不可接受。
WS-BusinessActivity提供了一种基于补偿的long-running的事务处理模型。
还是上面的例子，服务器A的事务如果执行顺利，那么事务A就先行提交，如果事务B也执行顺利，则事务B也提交，整个事务就算完成。
但是如果事务B执行失败，事务B本身回滚，这时事务A已经被提交，所以需要执行一个补偿操作，将已经提交的事务A执行的操作作反操作，恢复到未执行前事务A的状态。
这样的SAGA事务模型，是牺牲了一定的隔离性和一致性的，但是提高了long-running事务的可用性。
简单的说，TCC就是一个乐观锁版本的2PC。
5.2.异常处理
一般使用一个result类型包装结果和错误信息。
微服务构架包括：
●分布式rpc（支持资源隔离和快速熔断）
●分布式消息队列（事务补偿）
●分布式缓存（快速）
●持续集成、自动部署工具（docker，jenkins）
●监控和分布式日志（flume）
事务的实现原理：
写时复制（这里指内存中的写时复制）、redo undo日志回滚、sharding page（文件写时复制技术，类似于docker镜像的layer）
5.3.微服务结构。