MongoDB:Read from slave dirctly,how to guarantee that the data is just up-to-date? I know that MongoDB is the master/slave architecture,to make the read faster,some read request is directly sent to slaves.But since it is a distributed system,when the data is write to a master,the master will write the data to an editlog,the slaves will read the log to synchronize data of itself.So, the data read directly from slave maybe just dirty data.So , what we can do to make sure that the data read from salve is just the up-to-date data?
Master/Slave replication is deprecated, will be removed in future versions and has no advantage over a replica set with two data bearing nodes and an arbiter (which is extremely cheap in terms of disk, CPU and RAM usage), safe for the fact that you don't need to run an arbiter. A replica set however offers automatic failover and some administrative advantages.

Another misconception you have is that replication (no matter which kind) is supposed to increase read performance. While you can use it for this, it is a very poor man's solution. I'd rather call it a highly impovered man's solution for performance scaling. Replica sets are MongoDB's means of ensuring data availability and durability.

That being said: there is a way to ensure that the secondary nodes are consistent with the primary node of a replica set, but it comes at a cost - and not a small one. You can set the write concern in a way that a write is only considered successful when it is written to all nodes of a replica set. The problem is that this requires some round trips which make the write operation slow - by orders of magnitude in the worst case. Also, if one of your servers fails, write operations with a write concern of "all" will fail, since the nodes originally forming the replica set are taken into account, not only the ones which are up. In case you can live with those drawbacks, you can even make absolutely positively sure that the data is written to the data files and not "only" the journal by setting the fsync option to true. Be warned that writes may take a VeryVeryLongTime(TM) to return with this option activated. I generally discourage it's use except for very special use cases.

For performance scaling, the solution offered by MongoDB is scaling out by means of sharding. When done correctly, you basically distribute your collections over several shards, thereby keeping a larger part of your working set in RAM and making read and write operations on the data files being done in parallel (document wise).