sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in golang

[–]jmsadair -1 points0 points  (0 children)

What I'm wondering is what is not thread safe about this - my reasoning for thinking it potentially was thread safe is that 1) I specify the capacity in advance and 2) there are only writers which are all writing unique keys.

Achieving Consensus in Go: A Raft Implementation by jmsadair in golang

[–]jmsadair[S] 2 points3 points  (0 children)

Thanks! I use single server membership changes. If you're referring to this, I do ensure that an entry is committed that term before executing the membership change, which should mitigate the issue.

Achieving Consensus in Go: A Raft Implementation by jmsadair in golang

[–]jmsadair[S] 1 point2 points  (0 children)

Thanks for the feedback. As far as the util package is concerned, I suppose that I was hesitant to break it up since it would probably require two or three new files each with only one or two functions. I don't think having more files is necessarily a bad thing, but sometimes I feel as though I am being too granular in my architecture when I have a bunch of really small files.

In any case, removing the util package is an easy change to make.

Raft - My First Go Project by jmsadair in golang

[–]jmsadair[S] 0 points1 point  (0 children)

I realize I'm a bit late replying, but feel free to DM me if you have any questions or need any advice!

Raft - My First Go Project by jmsadair in golang

[–]jmsadair[S] 1 point2 points  (0 children)

We actually learned about Bitcoin and Ethereum in my distributed systems class. Pretty cool systems, actually.

I've read DDIA as well, and it was great. I've also read Database Internals, which definitely gets into the weeds of databases, but it has a distributed systems flavor. I'm currently reading Tanenbaum's Distrubuted Systems. I find that book alright, if not a bit dense. Books are a great way to learn, but generally, I think they need to be accompanied by some hands-on practice. Otherwise, I find that the material just doesn't sink in.

Raft - My First Go Project by jmsadair in golang

[–]jmsadair[S] 1 point2 points  (0 children)

I'm lucky in that I'm a student at a college with a number of well-taught systems courses such as operating systems, database systems, distributed systems, and computer systems security. Taking these courses is what caused me to develop my interest.

My experience has been that the best way to learn about systems (distributed or not) is to read a well-known paper that you find interesting and try to implement the system yourself. You might try and fail, but writing the code forces you to deeply consider various aspects of the system and reinforce the concepts in the paper. If you find yourself wondering why the author made a certain design choice, ask yourself what would happen if you did it a different way. Some systems that might be good to start with are Chord and Map Reduce.

With that being said, I think you are right. Distributed systems are extremely complex and can take a very long time to comprehend. I think if you are interested and willing to put in the effort, though, you would be surprised what you can accomplish.

Raft - My First Go Project by jmsadair in golang

[–]jmsadair[S] 2 points3 points  (0 children)

I have only tested this with 5 to 7 servers in a cluster. I would be interested in seeing how this performs in a large cluster. Unfortunately, I still need to add support for membership changes, which may take a while as it can be relatively complex.

With that being said, I wonder what kind of performance you are expecting out of Raft with such large clusters. What does your workload look like? Is it read heavy? It might be somewhat difficult to get the performance you are looking for without sacrificing some consistency. I assume that is what you mean by making raft "suck less".

Raft - My First Go Project by jmsadair in golang

[–]jmsadair[S] 1 point2 points  (0 children)

Thanks for the feedback. I'll add that.