One database, multiple frontends, maintaing request ordering_问答_开发者

Assuming I have one database keeping a simple history with multiple front ends talking to it (one front end per server), I wonder what are the common solutions to deal with time. As soon as I have multiple servers, I cannot assume a global consistent clock, and I was interested in the possible solutions to maintain some kind of ordering between requests.

For a concrete example, let's say I want to record histories of customers, where history is defined as time ordered set of records. The record table would be as simple as (customer_id, time, data), and history would be all the rows where customer_id == requested id. Each request sent by the user would contain one record sent to one customer. Ideally, the time should refer to the "actual" time the request was sent to the front end by the customer (as that's the time as seen from the user POV). To be exact, I only care about preserving the ordering between records for each customer, not about the absolute time.

I am aware of solutions such as vector clocks, etc... but that seems rather complex, and I would expect this to be a rather common issue ?

Solutions which are not acceptable in my case:

Changing the requests arriving at the front end: I unfortunately have to work under the constraint that the requests are passed as is. I have complete control of whatever communication protocol is needed between front ends and database, though.
Server time clocks are synchronized
All request which require being ordered to each oth开发者_StackOverflow社区er are handled by the same front end server

[EDIT]: the question may sound a bit like red-herring, so here is my rationale for asking it: while this is not my issue right now, I am interested in the possibility to go to a platform like Google App Engine, which explicitly says that their servers are not guaranteed to be time synchronized. The solution to that issue for request ordering does not sound obvious to me - but maybe something like vector clock is actually the only "good" solution ?

When you perform any action that records history data to the database you could record two sets of datetime info:

the datetime as set by the DB when the record was inserted
the datetime passed through with the data as a legitimate piece of metadata.

The former would give you a central view of the world if you ever needed it, and the latter would let you reconstruct datetime from customers perspective.

If you were ultra-keen you could also pass through the datetime from the users browser by filling some sort of parameter/field using JavaScript.

As soon as I have multiple servers, I cannot assume a global consistent clock

Well, you can configure servers to sync their clocks to a time server. You could also configure your database server to sync to a time server, and configure the other servers to sync to your database server as often as you need to. (I'm not saying that's a great idea, just saying it's possible. If you have access to all the servers.)

Anyway . . . so the front ends are the only pieces of software you have that actually know when a request arrives. Is that right?

If that's right, then it's the front ends job to record the time of the customer's request, possibly in UTC, and then forward that timestamp to the database.

If you can't synchronize the server's clocks, then I think your only hope is to have every front ends ask just one specific server--maybe your database server, but maybe not--what time it is when a customer request arrives. A front end can do that by asking for daytime on port 13 (DAYTIME protocol, RFC-867), asking for time on port 37 (TIME protocol, RFC-868), or asking a time server on port 123 (either NTP or SNTP protocol, RFC-1305 and RFC-2030).

But after reading your edit, I think what you want is impossible. You seem to be saying that