這是一個大作業，大工程。
還沒寫完。打算總結下，以后面試方便回憶。
先做幾個記錄。
對于這種大型分布式系統，加多線程安全的復雜問題，一定要用Log類。
否則debug 的時候你就是瞎子。
為什么debug到最后，都是一些小問題出現了錯誤？整體邏輯一直是對的，所以最難找的bug一直找不出來。消耗了大量時間后，才找到bug，然后是微乎其微的一個bug，本來覺得肯定不會寫錯的。
那么，該如何避免這個錯誤？
分布測試？有時候太懶，覺得一個功能太簡單，肯定是對的。所以就不測試了。因為寫測試程序本身也很煩，很枯燥。
其次。還有一個小bug是復制代碼的時候出現的。
之前寫的代碼。這里為了減少麻煩，直接復制過來。
但是忽略了一個參數，在那時候是不變的，為0.這個時候是變的，跟我的輸入參數有關。我也沒注意到，覺得肯定是對。
然后就錯了。
很有趣的現象。
我為什么不肯直接自己寫？因為覺得太簡單了。自己也完全理解了。完全可以復制過來的。
然后，就沒有然后了。
但是難道你要強迫我每次代碼都自己完整敲完嗎？
感覺這樣效率很低。
也不知道該怎么做。如果有人看到這篇文章，看到這里，可以給一些建議
繼續測試去了。
待續。。。
突然發現簡書編輯界面 和一款軟件 Quiver 好像。。。
This project is divided into two parts, one is to write scripts to start instances, connect with Amazon simpleDB, write data into it and get data from it. The other part is to write a scalable and consistent website.
I use one script to start N instances on AWS platform and then transfer one install script to instance. Then this script will be blocked until N instances have be registered on Amazon simpleDB. After unblocked, it will start to transfer the servlet war file into instances and finish its work.
When instances are running, they will automatically run the transferred script as root. This install script will help instance to configure running environment, such as Java 8, Tomcat and so on. Then it will get connects with SimpleDB, creates a table if table doesn't exist, write its ami-index (server id) and ip into this simpleDB, and then keep blocked until one time N instances have all be registered on the simpleDB. And then each instance will get data of all instances stored in simpleDB back and write it into tomcat/webapps directory. It should be in JSON form. And then this script will be blocked until the servlet war file has been uploaded into this instance.
After that, it will start the tomcat and the servlet will be loaded.
Then it should be the most important part of this project, to build a scalable, consistent and fault-tolerant distributed website.
To be brief, I am trying to implement the SSM protocol which is to write new sessions into W servers but it only needs WQ successful write operations. It means we randomly write data into WQ distributed servers. For session read, it will randomly pick R servers to read from WQ successfully written servers and only need one successful read.
Sessions in these WQ servers are totally same including their expired date. This is the session consistency.
What's more, this website is (WQ - 1) resilience. It means even though WQ - 1 servers are down, I can still read the stored session back. This is the fault tolerance.
Finally, stability and safety of this website will increase when the number of servers increases. This is the scalability.
Therefore, it is a consistent, fault-tolerant and scalable website based on SSM protocol.
More details:
The servlet consists of three parts.
garbage collector. It is used to remove those expired sessions from session table. It is a thread and will start to work in a period time.
RPC_Server. It is used to wait for the read or write request from RPC_CLient. It is also a thread created during initialization of servlet. After running, it will keep listening to the specified port for the client request.
RPC_Client. It is used to send read or write request to RPC_Server. Because we need to send several read or write requests, so I design a specified monitor and lock to make these request parallel.
Then I will show more details in session read and session write.
For session read, it will firstly get the IDs of WQ servers from the cookie and send read request to these servers. After receiving request, servers will return the session including its expired date to RPC_Client. And then this servlet will generate a new expired date for this session and randomly write it into WQ servers. This behavior ensures the consistency of sessions in distributed servers. To be more specific, those WQ servers will have the same expired date for this session. If one is expired, the other must be expired. It is the consistency. And all sessions are also same, it is still the consistency. And then it will add the server ids of those WQ servers into the cookie so that next time, servlet can use this cookie to find these WQ servers and read the stored session from it.
For session write. Firstly, it will read session from WQ servers depending on the cookie. And then update the message and expired date of this session. And then randomly write into WQ servers and add their ids into the cookie.
