我们将问题分为两部分来回答：一是使用 Redis 或 Hazelcast 确保数据一致性后是否仍需 Oracle 或 MySQL 等数据库；二是能否仅用两台服务器实现集群的高可用性。以下是详细探讨：

是的，通常仍需要数据库，尤其是当您的应用需要持久化存储、复杂查询或满足 ACID 事务要求时。

Redis 和 Hazelcast 的作用
Redis 和 Hazelcast 是内存数据存储，主要用于缓存、会话管理或快速数据访问。它们擅长在分布式系统中保持数据一致性并提供低延迟操作，但并非为长期持久化存储设计：
- Redis：虽然可以持久化数据到磁盘，但其核心优势是速度，而非数据的持久性。它常作为数据库前置缓存来减轻负载。
- Hazelcast：类似地，它提供分布式缓存和内存数据网格，但也不是传统数据库的完全替代品。
Oracle 和 MySQL 的作用
像 Oracle 或 MySQL 这样的关系型数据库提供以下功能：
- 持久化存储：即使系统重启或故障，数据依然保留。
- 复杂查询：支持基于 SQL 的复杂数据关系查询。
- ACID 合规性：确保事务的原子性、一致性、隔离性和持久性，这对许多业务应用（如金融系统）至关重要。
是否需要两者结合？
在大多数企业应用中，Redis 或 Hazelcast 和数据库各有分工：
- Redis/Hazelcast：用于缓存频繁访问的数据，减少数据库压力，提高性能。
- Oracle/MySQL：用于存储关键的长期数据，确保持久性和事务完整性。

可以，但有局限性。两台服务器能提供基本冗余，但要实现真正的生产级别高可用性，建议使用更多节点或附加机制。

基本高可用性
使用两台服务器，您可以配置主从（或主备）模式。如果主服务器故障，从服务器接管，确保服务持续运行：
- Redis：通过 Redis Sentinel 可以管理两节点间的故障切换。
- Hazelcast：内置集群功能也支持两节点配置。
局限性
- 脑裂问题：如果两台服务器间的网络断开，每台都可能认为对方已宕机并尝试成为主节点，导致数据不一致。
- 负载均衡：两台服务器可能无法有效分担高流量负载。
- 扩展性：随着应用增长，两节点可能不足以应对需求。
改进建议
- 增加第三组件：如仲裁节点或外部协调者，帮助决定哪台服务器应为主节点，避免脑裂。
- 推荐三节点集群：三台服务器可实现基于多数决（quorum）的决策，提升可靠性和负载分担能力。

技术选择
- Redis/Hazelcast：适合缓存高频数据、管理分布式会话或实时数据共享。
- Oracle/MySQL：适合存储需要持久化和复杂查询的关键数据。
高可用性配置
- 两台服务器：适合初级冗余，但需警惕脑裂风险，可通过仲裁机制弥补。
- Redis：建议搭配至少三个 Redis Sentinel 实例，确保可靠的故障切换。
- Hazelcast：推荐三节点集群，以实现自动故障转移和数据一致性。