Re: Java Server Frame(Dual Hot Backup+ Database)
sss.zhou@gmail.com wrote:
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.
--
Lew