Java Server Frame(Dual Hot Backup+ Database)

[sss.zhou]

I wanted to design a server java server application, which was
anticipated to supply services for 365 * 24 hours continuously. For
this reason, Dual Hot Backup must be applied. (Without this, our
customers will never give you a change). And also it contained a
database and I also included a memory database (HSQLDB) in my server
application for two reason. One is that some request must be responded
with 30ms and another is when database service is crashed my services
will go on.

As everyone know the 100 percent stably server is not exist. I
just want to find a most high Cost-effective frame to my application.
The frame of my system is three server machines, one installed
the disk database(for example: MySql) and two others install my server
application and a memory database.

Just see my ugly design chart(I don't know the Google groups
will layout it correctly as my wish) :

|--------Client -----------|
| |
| Clients |
| ^ |
| |(req/rsp) |
| | |
| v |
| Server Proxy |
|--------------------------|
/ \
(PING AND DATA) (PING AND DATA)
/ \
|--------Server 1-------------| |-----------Server
2-------------|
| Main Service Server | | Backup Service Server |
| (Memory DataBase) | | (Memory DataBase) |
|--------------------------------|
|----------------------------------|
\ /
\ /
\ /
|--------Server 3----------|
| Disk DataBase |
|------------------------------|

Any one of the server machine is crashed, the system need to
keep on working.
Case1: Main Server is crashed, the backup server and database
can provide the whole service.
Case2: DataBase is crashed, any of the sever can provide the
whole service and buffered the data to Memory database.
I using a Server Proxy connect to both servers and send
requests to the proper server.

I have been working using C++ for many years and I just learnt
that using java to write this sort of application has many benefits.
But I was not experienced in java, so I need some advices of my
design. Until now, I have found that data synchronization is a big
trouble in my design and I can't find a better way.
Thanks all for concerned my post.

 

[sss.zhou]

That text chart is too ugly, I changed it, sorry
|--------Client -----------|
| |
| Clients |
| ^ |
| |(req/rsp) |
| | |
| v |
| Server Proxy |
|--------------------------|
/ \
(PING AND DATA) (PING AND DATA)
/ \
|--------Server 1-------| |--------Server 2--------|
| Main Service Server | | Backup Service Server |
| (Memory DataBase) |--(JUST PING)--| (Memory DataBase) |
|-----------------------| |------------------------|
\ /
\ /
\ /
|--------Server 3----------|
| Disk DataBase |
|--------------------------|

 

[Lew]

That text chart is too ugly, I changed it, sorry
|--------Client -----------|
| |
| Clients |
| ^ |
| |(req/rsp) |
| | |
| v |
| Server Proxy |
|--------------------------|
/ \
(PING AND DATA) (PING AND DATA)
/ \
|--------Server 1-------| |--------Server 2--------|
| Main Service Server | | Backup Service Server |
| (Memory DataBase) |--(JUST PING)--| (Memory DataBase) |
|-----------------------| |------------------------|
\ /
\ /
\ /
|--------Server 3----------|
| Disk DataBase |
|--------------------------|

I wouldn't use Java necessarily to handle data reliability or replication.
Products such as slony for PostgreSQL have already solved master-slave data
replication, and the DB engines are optimized for things like caching, query
planning and the like. Java is also one of the languages you can use in
Postgres or Oracle stored procedures.

If your databases are accepting updates into the replicants (in your
configuration, the "memory" databases) you have a synchronization /
reconciliation problem.

Put data reliability in the data layer of your architecture, not the
middleware layer.

I should think more traditional architectures would give you the reliability
you seek: hot-swap RAID arrays, failover dataservers with efficient tuned
caches, replication through proven third-party products, people keeping an eye
on the production servers and fixing things before the clients notice a problem.

Thinking Java will solve all your problems is like a carpenter thinking they
only need a hammer in their toolbox.