焦虑的程序员--关于“不一致”

睡不着~

/**
	 * 根据“最小知识”原则，此处不做异常处理，因为没有足够的信息做处理，如果硬要处理会局限该接口的使用场景。
	 * 如果外围觉得有异常不可接受，可以自行处理。
	 * 资源回收在此也不合理，因为dispatch只是消息资源的使用方，而非拥有者，不具备销毁资源的权利
	 * 资源回收应该秉着谁生产资源，谁负责回收资源的原则。使用方没有任何资格销毁资源，但可以清空与资源的联系
	 */
	public boolean dispatch(final Runnable message) {
		return TaskMessage.aquireNew().setRunnable(message).schedule();
	}

	/**
	 * 该组件的“服务实例”的轮询逻辑会监听组件的运行状态，而执行这个方法时组件已经是Stopped状态了，
	 * 所以理论上：如果各个服务实例正在执行service()中的逻辑，那么这将是“最后一次执行”，
	 * 但是很不幸，这次执行如果和stop()并行的话，那么结果肯定不会是“成功的”，因为stop()调用会开始释放该组件所持有的资源,从而影响资源的可用性。
	 * 
	 * 恩，这时就有一个问题了：	
	 * 		组件所拥有的资源并非都是“无状态”的，对于“有状态”的资源是否能成功的释放掉呢？
	 * 		比如一个资源的状态是“使用中”（很正常啊，正在被某个服务实例使用），那么对该
	 * 		资源的释放是否能确保成功呢？如果没释放成功那么会有什么后果呢？
	 * 						
	 * 		在本系统中，组件的服务实例只有各种资源的“使用权”，而资源的“生命周期”的控制权归服务组件所有。
	 * 		而服务组件对资源的释放是具有“强制性”，这样做是不希望服务组件“关心太多资源的细节”，这样比较“简单直接”。
	 * 
	 * 		俄。。。，但是这种“简单直接”会不会给正在使用此资源的“服务实例”带来严重的运行后果呢？
	 * 		如果后果严重那便不是“简单直接”而是“简单粗暴”了。哎。。。。纠结啊
	 * 
	 * 分析下对服务实例的伤害的：
	 * 		真正关心的伤害本质上是那些对对持久化数据资源产生影响的伤害，也就是产生“不一致”数据。
	 * 
	 * 		但是“不一致”这个词具有很强的业务性。
	 * 		该系统设计的初衷之一是实现和业务逻辑的独立，所以如果设计成功，
	 * 		那么必将对接一个问题领域中的各种业务，而这些业务之间是千差万别的。
	 * 
	 * 		如果本系统致力于在系统内解决stop过程中的“不一致”问题，
	 * 		那么，业务间巨大的差异，繁多的种类 会导致解决策略抽象难度加大，
	 * 		从而导致doStop()方法中需要扩展的策略逻辑增多，最终超出了一个方法所应该承载的功能量，
	 * 		并且对于长周期多步骤全网业务是不可能解决的（这些业务的执行过程中不可能不停机吧）
	 * 		这显然已经远远超出了本系统该解决问题的边界。
	 * 		
	 * 		所以数据“不一致”是一个很大的话题，之所以大因为是和业务强相关的，所以不可能在一个系统内解决
	 * 		换句话说，本系统的行为可能导致的“不一致”问题，但这并不代表就该由本系统来解决这个问题。
	 * 		所以，如果想在当前的场景下避免“不一致”是不现实的，过分追求必将陷入迷思。
	 * 		
	 * 		所以，“问题”引导思考需求，但最终的系统应该是在满足确定的需求边界的功能的前提下追求更高的“确定性”
	 * 		而对于当下的doStop()而言，我们不指望在这个过程中服务实例能很好的避免什么问题，但是应该有
	 * 		更为确定的行为方式，也就是“优雅的结束”
	 * 	
	 * 		即：	服务实例可以完整的走完service()方法。而且service()中的逻辑也不用考虑依赖的服务组件的资源的“可用性”问题的以及当前组件的状态，
	 * 			他可以安心做完本次调用,因为服务组件会等他调用完后才开始释放资源。
	 * 
	 * 暂行策略：
	 * 		一方面我们希望在stop的过程中对资源的释放具有强制性，一方面我们希望这种期望对服务实例可优雅结束。
	 * 		在释放资源之前，卸载所有的服务实例后通知服务组件执行doStopprocess()进行资源释放。
	 * 		这里的doStop()实际上进行的是异步处理，从这个角度可以更好的理解，类和实例管理的只是指令资源，具体的执行方式真是千万别啊，
	 * 
	 */
	protected void doStop() {
		serviceInstanceKeeper.notifyAllServiceInstanceToStop();
		// 等待所有的实例都停止
		while (getServiceInstanceCount() > 0) Thread.yield();
		// 开始执行停止服务的操作
		this.doStopProcess();
	}