问题一：PolarDB-SCC中的分层细粒度修改跟踪是如何工作的？
PolarDB-SCC中的分层细粒度修改跟踪是如何工作的？
参考回答：
在PolarDB-SCC中，RW节点会维护全局、表级、页面级的更新时间戳。当RO节点处理请求时，它会首先获取全局的时间戳，如果这个时间戳比RO节点回放日志的时间戳小，RO节点不会立即等待，而是会继续比较请求需要访问的表、页面的时间戳。只有当需要访问的页面的时间戳仍然不满足时，RO节点才会等待日志回放，这样可以避免一些不必要的日志回放等待。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/639394
问题二：为什么PolarDB-SCC选择基于RDMA的日志传输？
为什么PolarDB-SCC选择基于RDMA的日志传输？
参考回答：
PolarDB-SCC采用基于RDMA的日志传输，主要是因为RDMA接口能极大地提高日志传输速度，同时减少了日志传输时带来的CPU开销，有助于实现低延迟的全局一致性读。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/639395
问题三：PolarDB-SCC与其他数据库相比有何优势？
PolarDB-SCC与其他数据库相比有何优势？
参考回答：
与其他数据库相比，PolarDB-SCC能在几乎没有性能损失的情况下实现全局强一致读。在我们的测试中，只有PolarDB-SCC可以完全避免读到过期数据，而其他测试的数据库（如DB-A、DB-B和原始的PolarDB）在RO节点上都会返回过期的数据。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/639396
问题四：PolarDB-SCC的总体架构是怎样的？
PolarDB-SCC的总体架构是怎样的？
参考回答：
PolarDB-SCC采用了基于共享存储的一写多读架构，包含一个读写（RW）节点和多个只读（RO）节点。RW和RO节点可以进一步连接到代理节点上。代理节点可通过将读请求分发到RO节点并将写请求转发到RW节点来实现读写分离，从而提供透明的负载平衡。RW节点和RO节点通过基于RDMA的网络连接，可快速传输日志和获取时间戳。
PolarDB的事务系统是一套重新设计的基于时间戳的事务系统，其完全重构了MySQL基于活跃事务数组的传统事务系统，以支持分布式的事务扩展和提升单机性能，这是PolarDB-SCC的基线。 
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/639397
问题五：PolarDB-SCC的核心设计主要有什么？
PolarDB-SCC的核心设计主要有什么？
参考回答：
主要是以下三个：
（1）线性Lamport时间戳。由于最新修改的时间戳保存在RW节点上，因此RO节点必须在每次处理请求时从RW节点获取该时间戳。虽然RDMA网络速度很快，但如果RO节点的负载很重，开销仍然很大。为了减少时间戳获取的开销，我们提出了线性Lamport时间戳。在线性Lamport时间戳的基础上，RO节点从RW节点获取时间戳后，可将其存储在本地。任何早于该时间戳到达RO节点的请求都可以直接使用本地存储的时间戳，而不用从RW节点获取新的时间戳。当RO节点负载较重时，这可以节省许多获取时间戳造成的开销。
（2）分层的细粒度的修改跟踪。在RW维护全局、表级、页面（page）级的更新时间戳。当RO处理请求时，首先获取全局的时间戳，如果全局时间戳比RO回放日志的时间戳小，RO不会立即进入等待，而是继续比较请求需要访问的表、page的时间戳。只有当需要访问的page的时间戳仍然不满足时，才会等待日志回放。这样可以避免一些不必要的日志回放等待。
（3）基于RDMA的日志传输。PolarDB-SCC采用了单边RDMA的接口来实现RW到RO的数据传输，极大地提高了日志传输速度，同时减少了日志传输时带来的CPU开销。
关于本问题的更多回答可点击原文查看：
