假设我有像这样的SQL架构 -
create table master_lock(job_type int primary key, ip varchar);
现在每个节点都尝试插入一个像this-
这样的值insert into master_lock values(1,192.168.1.1);
insert into master_lock values(1,192.168.1.2)
无论哪个节点能够成功插入，现在都可以被视为主节点。我们可以在sql表中添加一个新的列时间戳，以便删除那个陈旧的锁。
通过这种方案，我可以轻松选出一个主节点。 为什么我需要Paxos / Raft等？
答案 0 :(得分：1)
Who says you need Paxos/Raft/etc? What you describe is essentially a distributed, atomic Compare-And-Swap operation. You could use any number of mechanisms to do so and a SQL database will work just fine. Your idea for adding in an additional timestamp that must be continually refreshed to retain master status is a common pattern in this arena and it's often referred to as "Master Leases".
Depending upon your application and it's intended operating environment, using a designated third party to arbitrate between peers (which is the role the SQL database fills in your example) might be your best option. It introduces a single point of failure but it's super simple and periodic downtime maintenance windows may be tolerable, again depending on the application. The potential advantage of something like Raft or Multi-Paxos is that there is no single point of failure. As long as a quorum of peers are available, the ability to choose and maintain the master peer is available. The up-front implementation is probably an order of magnitude more complex but you remove the single point of failure and gain a measure of overall architectural simplicity by removing the concept of the designated 3rd party.
Ultimately, it depends on what you're trying to do and the level of robustness you need. Is the maintenance burden and potential downtime of a SPOF a deal breaker for your app? If yes, go Raft/Multi-Paxos. If not, honor the KISS principle and go the designated 3rd party route.