这是一个大作业，大工程。
还没写完。打算总结下，以后面试方便回忆。
先做几个记录。
对于这种大型分布式系统，加多线程安全的复杂问题，一定要用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.