微服务间事务处理最优解决方案
现状：无微服务间事务
期望：其他更优解决方案，比如Seata？
Seata（Simple Extensible Autonomous Transaction Architecture）是一个开源的分布式事务解决方案，它由阿里巴巴开源。Seata 提供了 AT（自动事务）、TCC（尝试-确认/取消）、Saga 等事务模式，可以与Dubbo、Spring Cloud、gRPC等框架结合使用。
Dubbo 也不直接支持分布式事务，但可以通过以下方式实现：
Seata: Seata 支持 Dubbo，并提供了相应的集成插件。
阿里一般早期使用HSF， dubbo用的不如HSF多，近几年各自都有使用。
三种分布式事物模式介绍
AT 模式：
- 是一种基于关系型数据库的分布式事务解决方案。它基于两阶段提交（2PC）协议的演变而来，但又有自己的特点。在 AT 模式中，事务协调器（TC）会记录事务的相关信息，包括分支事务的状态等
- 适用于微服务架构下，各个服务主要基于关系型数据库进行数据操作，且事务相对简单，如电商系统中的订单创建与库存扣减等场景
TCC 模式（Try - Confirm - Cancel）
- 相比 AT 模式，TCC 模式的灵活性更高。它可以适用于更复杂的业务场景，包括一些非数据库操作的事务，如调用外部服务、消息发送等。
- 对业务代码的侵入性较大。开发人员需要手动编写 Try、Confirm 和 Cancel 三个阶段的具体业务逻辑，增加了开发的难度和工作量。
- 实现难度较大，需要考虑很多复杂的情况，如幂等性（确保相同操作多次执行的结果相同）、空回滚（在没有执行 Try 阶段直接执行 Cancel 阶段的情况）、悬挂（Cancel 阶段在 Confirm 阶段之后执行）等问题
- 适用于涉及复杂业务逻辑的分布式事务场景，如金融系统中的转账、支付结算等业务，或者需要对外部服务调用进行事务管理的场景。
SAGA 模式
- 原理：SAGA 模式是一种将长事务拆分成多个短事务的模式。它通过一系列的本地事务来实现分布式事务。每个本地事务都有对应的补偿事务。
- 应用场景：适用于工作流、业务流程编排等长事务场景，如电商系统中的订单全流程处理（包括下单、支付、发货、收货等多个环节）或者企业资源规划（ERP）系统中的复杂业务流程。
微服务间调用最优解决方案
现状：Feign调用、HttpURLConnection调用
期望：其他更优解决方案
dubbo框架，Dubbo 是一个 RPC（远程过程调用）框架，它的服务调用更像是本地方法调用的远程扩展。在内部通过代理等机制实现服务发现、调用和结果返回。这种调用方式相对 Feign 基于 HTTP 接口的调用来说，不太直观。在测试时，需要考虑更多的内部机制，如服务注册中心的状态、负载均衡策略、集群容错等对服务调用的影响。
Dubbo 框架本身对分布式事务有一定的支持：与 Seata 框架集成
- Seata 是一款开源的分布式事务解决方案。Dubbo 可以与 Seata 集成来处理分布式事务。当一个 Dubbo 服务调用涉及多个数据库操作或者多个微服务的操作时，Seata 能够保证这些操作要么全部成功，要么全部失败。
- 例如，在一个电商系统中，订单服务调用库存服务来扣减库存，这两个操作分布在不同的服务中。通过 Seata，会有一个全局事务来协调这两个分支事务（订单服务事务和库存服务事务）。Seata 采用了两阶段提交（2PC）的变种协议来实现事务的一致性。
大数据处理的解决方案（TB级就行）
现状：无系统，想做大数据处理展示系统，一部分实时性、一部分天、月、年数据写入读取
期望：一套大数据解决方案
内部使用 存储层odps、 计算层datastudio、展示层fbi报表
选型考虑的点：
1、易用性：使用要广泛，容易找到资料，上手成本。
2、可靠性：要靠谱，企业级大数据最怕的是不稳定
3、低成本：免费、开源、硬件成本
推荐的开源生态：Hadoop生态系统
Hadoop Distributed File System (HDFS)
功能: 分布式文件系统，用于存储大规模数据。 特点: 高容错性、高吞吐量、适合大规模数据存储。
YARN (Yet Another Resource Negotiator)
功能: 资源管理和调度框架，负责集群资源的分配和任务调度。 特点: 支持多种计算框架（如MapReduce、Spark、Flink等）在同一集群上运行。
MapReduce
功能: 用于大规模数据集的并行处理，支持批处理任务。 特点: 简单易用，但不适合实时或交互式查询。
Hive 功能: 数据仓库工具，提供SQL接口进行数据查询和分析。 特点: 适合大数据的批量处理和复杂查询，易于使用。
Pig 功能: 高级数据处理语言，使用Pig Latin编写脚本进行数据处理。 特点: 适合复杂的ETL操作，提供了丰富的数据处理操作符。
HBase 功能: 基于HDFS的分布式NoSQL数据库，支持实时读写访问。 特点: 高性能、可扩展性强，适合需要低延迟访问的应用。
ZooKeeper 功能: 分布式协调服务，用于维护配置信息、命名、分布式同步等。 特点: 提供高可用性和一致性保证。
Oozie 功能: 工作流调度系统，用于管理Hadoop作业的依赖关系和执行顺序。 特点: 支持复杂的作业调度和监控。
Sqoop 功能: 用于在Hadoop和关系型数据库之间传输数据。 特点: 支持导入和导出数据，简化数据迁移过程。
Flume 功能: 日志收集系统，用于高效地收集、聚合和移动大量日志数据。 特点: 可靠性高，支持多种数据源和目标。
Kafka 功能: 分布式消息队列系统，用于实时数据流的传输和处理。 特点: 高吞吐量、低延迟，支持发布/订阅模式。
Spark 功能: 大规模数据处理框架，支持批处理、流处理、机器学习和图计算。 特点: 性能优越，易于编程，支持多种语言（Scala、Java、Python、R）。
Flink 功能: 实时流处理和批处理框架，提供低延迟和高吞吐量的数据处理能力。 特点: 支持事件时间处理，适合复杂的流处理场景。
Hadoop生态的优点：
高可靠：HDPS 冗余存储
灵活：多种计算框架，与其他框架结合使用
低成本：对机器硬件配置要求不高
分库分表的必要前提，最优解决方案
现状：分库分表、数据库间dblink用连接，会造成system空间很大等问题
期望：其他什么好的方案
必要性评估：
- 数据量和性能瓶颈：当单表的数据量达到一定规模，比如数百万行甚至更多，或者数据库的读写请求压力过大，导致查询性能下降、响应时间变长，影响到业务的正常运行时，才需要考虑分库分表。这是最主要的前提，如果当前数据库的性能和数据量在可接受范围内，分库分表可能会带来不必要的复杂性。
- 业务可拆分性：业务逻辑上能够支持数据的拆分。如果业务紧密耦合，数据之间的关联关系非常复杂，分库分表可能会导致业务逻辑难以实现，或者需要大量的额外工作来处理跨库跨表的关联查询。因此，在考虑分库分表之前，需要对业务进行梳理和分析，确保业务能够适应数据的拆分。
数据库层面的解决方案：
- 垂直分库：
- 概念：按照业务的不同将一个数据库拆分成多个独立的数据库，每个数据库中包含相关业务的数据表。例如，将电商系统中的用户信息、商品信息、订单信息等分别存储在不同的数据库中。
- 优点：可以降低业务之间的耦合度，使得每个业务模块都有自己独立的数据库，便于管理和维护；可以根据不同业务的特点进行针对性的优化，比如为用户模块的数据库配置更高的内存，为订单模块的数据库配置更高的磁盘 I/O 性能；提高了系统的安全性，不同业务的数据相互隔离，减少了数据泄露的风险。
- 缺点：无法解决单表数据量过大的问题；跨库的业务关联查询会变得复杂，需要通过接口调用或者数据同步等方式来解决。
- 垂直分表：
- 概念：基于数据库中的 “列” 进行拆分，将一个表中不经常使用或字段长度较大的字段拆分到扩展表中，原表只保留经常使用的核心字段。例如，对于用户表，可以将用户的基本信息（如用户名、密码、手机号等）保留在原表，而将用户的详细地址、个人简介等信息拆分到扩展表。
- 优点：可以减少单个表的字段数量，提高查询性能，避免跨页问题；对于字段长度较大的字段，拆分后可以节省存储空间；使表的结构更加清晰，便于开发和维护。
- 缺点：同样会增加业务逻辑的复杂性，对于需要同时查询多个字段的业务场景，需要进行表的关联操作。
研发态尝尝借助中间件进行数据操作，降低编码复杂度。
- MyCat：
- MyCat 是一个较为知名的开源分布式数据库中间件，基于 Java 编写，支持 MySQL 协议，可以作为 MySQL 的代理服务器使用。它不仅支持 MySQL 数据库的分库分表、读写分离等功能，还可以通过 JDBC 协议与 Oracle 等主流数据库进行通信。对于 Oracle 数据库，MyCat 可在一定程度上实现对其数据的分片管理和访问控制。
- 优点是易于部署和使用，对于项目来说相对透明，如果遇到升级等操作，只需要在中间件层面进行即可；具有跨语言、跨平台、跨数据库的通用性。
- 缺点是 SQL 支持相对较弱，可能需要对 SQL 语句进行一定的改写和优化。
- ShardingSphere：
- ShardingSphere 是一款开源的分布式数据库中间件，提供了分库分表、读写分离、分布式事务等功能。它支持多种数据库，包括 MySQL、Oracle、SQL Server、PostgreSQL 等，并且可以与现有的数据库系统无缝集成。
- 该中间件由 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar 三个主要组件组成，通过数据分片和路由来实现分库分表，原理是将数据划分为多个片段，每个片段存储在不同的数据库实例或数据表中，然后根据数据的分片规则将请求路由到对应的数据库实例或数据表上。
- 优点是具有灵活的扩展性、高可用性，并且能够简化开发和维护。
使用数据仓库/大数据引擎查询
- hive
- presto
- clickhouse
大文本的存储解决方案
现状：新系统产品想页面上输入纯文字会超过数据库字段最大值，用LOB类型处理会增加程序处理的复杂性
期望：大文本的存储取得方案
1、这很正常，根据业务需求
2、使用BLOB
3、对于特别大的文本，及时KB，几百KB，几MB。推荐使用对象存储服务（如AWS S3、Google Cloud Storage、阿里云OSS等）来存储大文本。这些服务提供了高可用性和可扩展性，并且可以通过API方便地进行管理和访问。
实现步骤：
上传文件：将大文本内容上传到对象存储服务。
获取URL：获取上传文件的URL。
存储URL：在数据库中存储文件的URL
Oracle统计信息设置优化方案
现状：数据量大了会造成统计信息过期，自动整理统计信息会失效
期望：如何防止自动整理统计信息会失效
能否尝试做个监控？
查询失效的统计信息 失效统计信息指数据已经变化显著，但统计信息未更新。这可以通过查询DBA_TAB_STATISTICS视图并结合DBA_TAB_MODIFICATIONS视图来检查。
数据缓存处理解决方案
现状：数据缓存基本没用
期望：推荐比较好的spring的缓存解决方案
注意事项：缓存中不要存储重要数据。
推荐redis，支持多种集群模式
不推荐memcache，可扩展性差
数据类型支持：
- Redis：支持丰富的数据类型，如字符串、哈希表、列表、集合、有序集合等。这使得开发者可以根据不同的业务需求选择合适的数据结构来存储和操作数据，例如可以使用列表实现队列、使用集合进行去重操作、使用有序集合实现排行榜等，大大提高了数据处理的灵活性和效率。
- Memcache：主要支持简单的键值对存储，数据类型较为单一。对于复杂的数据结构，需要在应用层进行额外的处理和转换，增加了开发的复杂度。
数据持久化：
- Redis：提供了两种持久化方式，RDB（Redis Database）和 AOF（Append Only File）38。RDB 是定期将内存中的数据快照保存到磁盘上，AOF 则是将所有的写操作命令记录到日志文件中，以便在服务器重启时可以重新执行这些命令来恢复数据。这使得 Redis 在数据的可靠性和持久性方面有很大的优势，即使服务器发生故障，也可以恢复大部分的数据。
- Memcache：数据仅存储在内存中，不支持持久化功能7。一旦服务器宕机或重启，所有的数据都会丢失，因此 Memcache 更适合用于缓存一些临时的、对数据丢失不敏感的数据。
