言归正传，下面总结下使用Java开发mongodb应用的一些点滴。在Java中和mongodb交互的最直接的选择就是使用MongoDB Java Driver，其下载地址是：http://github.com/mongodb/mongo-java-driver/downloads。总的来说，在Java中操作mongodb的API还是很简洁，下面对其一些常见的使用做些介绍。

1、连接数据库

和mongodb建立连接的示例代码如下：

	Mongo m = new Mongo("localhost",27017);
	DB db = m.getDB("db_test");

尽管这里获得了表示mongodb的db_test数据库连接的对象db，但这时并没有真正和mongodb建立连接，所以即便这时数据库没起来也不会抛出异常，尽管你还是需要catch它的实例化过程。mongodb的java driver对连接做了池化处理，所以应用中只需要实例化一个Mongo对象即可，对它的操作是线程安全的，这对开发使用来说真的是很方便。

2、取得DBCollection

mongodb中的collection在Java中使用DBCollection表示（这是一个抽象类，尽管你不必需要知道），创建DBCollection实例也是一行代码，和创建DB实例一样，这个操作并不涉及真正的和数据库之间的通信。

	DBCollection coll = db.getCollection("collection1");

要获得类似mysql中“show tables”功能，可以使用如下代码：

	Set<String> colls = db.getCollectionNames();
	for (String s : colls) {
	    System.out.println(s);
	}

3、插入文档

mongodb存储JSON格式的文档，而在Java中表示这种数据格式的最简便的类就是Map了。MongoDB Java Driver中提供的BasicDBObject就是个Map（它继承自LinkedHashMap并实现DBObject接口），它会将Map中的数据转换成BSON格式传输到mongodb。下面是插入文档的示例：

	DBCollection coll = db.getCollection("collection1");
	BasicDBObject doc = new BasicDBObject();
	doc.put("name", "kafka0102");
	doc.put("age", 28);
	doc.put("time", new Date());
	coll.insert(doc);

mongodb中每个插入的文档会产生个唯一标识_id。当调用coll.insert(doc);时，driver会检查其中是否有_id字段，如果没有则自动生成ObjectId实例来作为_id的值，这个ObjectId由4部分编码而成：当前时间、机器标识、进程号和自增的整数。
insert函数也支持插入文档列表：

insert(List<DBObject> list)

而提交操作也有update( DBObject q , DBObject o )、remove( DBObject o )。

4、查询文档

4.1、findOne

findOne是查询满足条件的第一条记录（不意味着数据库满足条件的只有一条记录），查询条件使用DBObject表示，示例如下：

	DBCollection coll = db.getCollection("collection1");
	BasicDBObject cond = new BasicDBObject();
	cond.put("name", "kafka0102");
	cond.put("age", 28);
	DBObject ret = coll.findOne(cond);
	System.out.println(ret);

返回结果是个DBObject，可以通过get(key)来取值。对于查询条件，可以通过嵌套多层来表示复杂的格式，比如：

	query = new BasicDBObject();
        query.put("i", new BasicDBObject("$gt", 50));  // e.g. find all where i > 50

4.2、find

find函数是查询集合的，它返回的DBCursor是DBObject的迭代器，使用示例如下：

	DBCollection coll = db.getCollection("collection1");
	BasicDBObject cond = new BasicDBObject();
	cond.put("i", new BasicDBObject("$gt", 20).append("$lte", 30));
	DBCursor ret = coll.find(cond);
	while(ret.hasNext()) {
	   System.out.println(ret.next());
	}

5、使用索引

创建索引语句如：coll.createIndex(new BasicDBObject(“i”, 1)); ，其中i表示要索引的字段，1表示升序（-1表示降序）。可以看到，DBObject成为java客户端通用的结构表示。查看索引使用DBCollection.getIndexInfo()函数。

6、MongoDB Java Driver的并发性

前面提到，Java MongoDB Driver使用了连接的池化处理，这个连接池默认是保持10个连接，可以通过Option进行修改，在应用中使用Mongo的一个实例即可。连接池中的每个连接使用DBPort结构表示（而不是DBCollection），并寄存于DBPortPool中，所以对DBCollection的操作并不意味着使用同一个连接。如果在应用的一次请求过程中，需要保证使用同一个连接，可以使用下面的代码片断：

	DB db...;
	db.requestStart();
	//code....
	db.requestDone();

在requestStart和requestDone之间使用的连接就不是来自于DBPortPool，而是当前线程中的ThreadLocal结构变量（MyPort中保持了DBPort成员）。

7、其他选择

尽管Java mongodb driver很不错，但就像很多人不使用JDBC而使用一些ORM框架，mongodb的java客户端也有其他的选择。
1）对POJO和DAO的支持。对于那些热衷ORM的人来说，Morphia（http://code.google.com/p/morphia/wiki/QuickStart）是个不错的选择，它通过在POJO中添加注释来实现映射，并提供对DAO的CRUD操作的支持。
2）对DSL的支持。Sculptor就是这样的东西，使用者编写中立的DSL文件，Sculptor将其翻译成代码。这通常不具有吸引力，除非是多语言的应用，能将DSL翻译成多种编程语言，否则除了增加学习成本，没什么收益。
3）对JDBC的支持。mongo-jdbc是这样的东西，但现在还是实验性质的。它或许是想亲近Java程序员，不过它显然不能完全兼容JDBC，而很多Java程序员对JDBC也并不感冒，所以它不是很值得使用。

8、参考资料

1、http://www.mongodb.org/display/DOCS/Java+Tutorial
2、http://api.mongodb.org/java/2.0/index.html

CAP

CAP理论是由Brewer远在2000年的PODC会议上提出来的。CAP指的是：Consistency、Availability和Partition Tolerance，下面简述此三者：

1、Consistency（一致性）：一致性是说数据的原子性，这种原子性在经典的数据库中是通过事务来保证的，当事务完成时，无论其是成功还是回滚，数据都会处于一致的状态。在分布式环境中，一致性是说多点的数据是否一致。

2、Availability（可用性）：可用性是说服务能一直保证是可用的状态，当用户发出一个请求，服务能在有限时间内返回结果。而这种可用性是不关乎结果的正确与否，所以，如果服务一致返回错误的结果，其实也可以称为其是可用的。

3、Partition Tolerance（分区容忍性）：Partition这个词不是常说的操作系统或数据库中的用语，而是指网络的分区。网络中的两个服务结点出现分区的原因很多，比如网络断了、对方结点因为程序bug或死机等原因不能访问。

对于CAP三者，Brewer给出的结论是三者在分布式环境中不能鼎力，一个分布式系统只能有限的实现两者要求，并且这个结论又被另一高人证明了一番。

一致性问题

一致性可分为强一致性和弱一致性，弱一致性又称为最终一致性。

在单机环境中，强一致性可以由数据库的事务保证。但在多机环境中，强一致性就很难做到。尽管可以使用2PC来实现分布式事务，但它的低性能（很多情况下满足不了可用性需求）使得不适合于互联网应用。这种强一致性效果的取得，其实是让提交处理过程同步化。

在多机环境中，通过使提交处理半同步半异步、或者全异步，取得最终一致性效果。例如数据库中的主从复制，在提交时就是主库同步从库异步，这对从库复制进度落后不多的场景很简单有效，但在从库落后主库很多时，如果应用还从从库读数据，就会读出脏数据，可以通过监控从库复制进度来选择读哪个从库以避免这个问题。在NOSQL模式下，以Dynamo为例，可以通过确定NRW的不同取值，可以做到同步、半同步半异步、或者全异步的效果。

最终一致性使得数据的提交效果具有延时性，而在一定的延时性范围内（比如1秒以内），应用的可用性就是OK的，比如提交后在客户端通过JS等停一段时间刷新页面就是要取得这种效果。

主从OR对等系统

像数据库这样的主从系统有着广泛的应用，它很适合于提交压力不会使得从库复制明显落后的场景。它的缺点是，当主从提交压力增大、或者存在耗时长的提交命令时，从库复制进度会明显落后于主库。在Cache+DB的应用场景下，Cache的填充时机和策略也会受到主从模式影响。如果在一个Session中提交DB后作废Cache，而由后续的（或并发的）另一个Session来再次设置Cache、并且数据是从从库获取，就很有可能缓存住脏数据，如果Cache时间很长，那问题可能就很严重了。可以变通的策略是，在一个Session中提交DB后不是作废Cache，而是更新Cache，并且数据是从主库获取或者直接从应用环境获取。主从的另一个问题是，它有提交单点，但是，如果主从能满足应用需要，在具有完备的主备切换的保证下，这个单点问题并不见得有多大。

因为Dynamo的时兴，对等系统成为另一种选择。对等系统解决了单点问题，有着高分区容忍性，但它的效果仍得商榷。NRW的不同取值会影响读写数据效果，多点提交带来的冲突解决也是个问题，尽管通常采用高版本替换低版本的粗暴策略。现在的NOSQL对等系统存储的是简单的kv，并且可以采用加机器来扩容，所以性能方面应该是可接受的（尽管常见的单机kv存储性能要比数据库高很多，但在对等系统中，因为其复杂性，换算下来单机的性能并不见得有多高）。

SQL和NOSQL各有其优缺点。如果存储一些实体数据并且查询提交只是根据唯一标识来，使用NOSQL也许就很合适。但像复杂的关系数据，使用SQL就更合适些。而就提交模式来说，如果并发提交的数据隔离性不好（比如需要同时对同一个数值做更新），那么对等系统的提交冲突就会增多，数据的正确性就会受到影响。

BASE

上面提到，在分布式环境中，CAP只能取两者。但是，因为网络分区的情况不可避免，并且它对可用性有着重要影响，所以互联网中的分布式系统多在一致性方面做些折中。虽然不能达到强一致性，但可以根据应用特点采用适用的手段来达到够用的一致性效果。比如，对于微博系统，当用户新增一条消息，能够达到用户能看到刚才发的消息、而他的follower们能在尽快时间看到他新发的消息的效果就可以了。而在实现时，就可以结合同步和异步多种策略、SQL+NOSQL多种存储方案来满足应用需要。

BASE（Basically Available、Soft state、Eventually consistent）是对CAP中的AP的延伸。

在单机环境中，ACID是数据的属性；而在分布式环境中，BASE就是数据的属性。ACID有“尖刻”之含义，所以单机环境的数据有着很高的要求。而因为分布式环境的网络分区性及复杂性，对数据也只能有“基本”的要求了。

从ACID到CAP和BASE，从单机到分布式，从SQL到NOSQL，互联网应用的大规模发展促使不断出现可替代旧方案的新技术。在技术选型方面，重要的是根据自己的应用特点选择自己能驾驭的技术。而现实的应用场景，也大多是多种技术方案的结合。