by ·0评论

已剪辑自: https://www.cnblogs.com/xrq730/p/6662232.html

问题描述

业务有一个需求，我把问题描述一下：

通过代理IP访问国外某网站N，每个IP对应一个固定的网站N的COOKIE，COOKIE有失效时间。
并发下，取IP是有一定策略的，取到IP之后拿IP对应的COOKIE，发现COOKIE超过失效时间，则调用脚本访问网站N获取一次数据。
为了防止多线程取到同一个IP，同时发现该IP对应的COOKIE失效，同时去调用脚本更新COOKIE，针对IP加了锁。为了保证锁的全局唯一性，在锁前面加了标识业务的前缀，使用synchronized(lock){…}的方式，锁住“锁前缀+IP”，这样保证多线程取到同一个IP，也只有一个IP会更新COOKIE。

不知道这个问题有没有说清楚，没说清楚没关系，写一段测试代码：

public class StringThread implements Runnable {

private static final String LOCK_PREFIX = “XXX—“;


privat[……]

阅读全文

by ·0评论

Json-lib的方式：

功能较为简单
对集合类的属性的映射需要手动配置
不支持注解配置

Double/Integer等包装对象，如果值为:null，序列化结果为:0

BigDecimal序列化会出现精度丢失的情况，如：19.90,转为json字符串，会变成19.9丢失后面的0

Jackson的方式：

支持注解配置
支持对jsonkey与属性名绑定

参考：

http://www.cnblogs.com/hoojo/archive/2011/04/22/2024628.html

http://www.cnblogs.com/hoojo/archive/2011/04/21/2023805.html

 

by ·0评论

重构

原因

需求变化

架构调整

最佳实践变化

原则

适用

实施

当需要改动的时候再进行优化

CSS样式的优先级：

CSS样式的特指度：（a,b,c,d）

如果用 style 属性应用样式，则 a=1，否则 a=0。

b 为 ID 选择器的数量。

c 为类选择器、属性选择器和伪类的数量。

d 为类型选择器和伪元素的数量。

根据特指度确定样式的优先级

！important为最高优先级

CSS子元素继承父元素的完整列表：  https://www.w3.org/TR/CSS21/propidx.html

CSS伪类

:link 样式应用于具有合法 href 属性的元素。

:visited 样式应用于具有合法 href 属性的超链接元素，并且浏览器的历史记录之中含 有该链接。

:focus 样式应用于获得焦点的超链接元素。当点击、轻触元素，或使用 Tab 键跳转到 当前元素时，元素获得焦点。outline属性有助于键盘访问视角展示

:hover 样式应用于鼠标光标悬浮于超链接之上时。触摸设备，没有光标悬浮状态。因此， 通常当轻触元素时，应用 :hov[……]

阅读全文

by ·0评论

已剪辑自: http://www.cnblogs.com/jiqing9006/p/4999670.html

用单数形式更佳，理由如下：
1、概念直观。 你有一个袋子，里面有好多个苹果，你会说这是个苹果袋。但无论里面有0，1，百万个苹果，它依然是个袋子。表也是如此，表明需要描述清楚，表里面包含的对象，而非有多少个数据。
2、便利性 单数形式更简单。有一些单词，它的复数形式可能是非常规的，或者就没有复数形式，但是单数不一样，单数形式则没那么多讲究。有些单词的复数，可能会想到你头大，可能得好好google才出来
3、优雅 特别是一些master-detail形式的资源名称，统一用单数，读起来更方便，对齐更整齐，从顺序上更有逻辑性。 对比下 单数： OrderOrderDetail 复数： OrderDetailsOrders
4、简单朴素 设想下，不管是表名，主键，关系，实例Classes，你都可以统一用单数，所有看上去那么统一，也不用费心地各种复数单数中转换你的思维 Customer、Customer.CustomerID、CustomerAddress、public Class Custo[……]

阅读全文

by ·0评论

Oren Eini（又名 Ayende Rahien）建议开发者尽量避免数据库的软删除操作，读者可能因此认为硬删除是合理的选择。作为对 Ayende 文章的回应，Udi Dahan 强烈建议完全避免数据删除。

 
 

所谓软删除主张在表中增加一个 IsDeleted 列以保持数据完整。如果某一行设置了IsDeleted标志列，那么这一行就被认为是已删除的。Ayende 觉得这种方法”简单、容易理解、容易实现、容易沟通”，但”往往是错的”。问题在于：

 
 

删除一行或一个实体几乎总不是简单的事件。它不仅影响模型中的数据，还会影响模型的外观。所以我们才要有外键去确保不会出现”订单行”没有对应的父”订单”的情况。而这个例子只能算是最简单的情况。……

 
 

当采用软删除的时候，不管我们是否情愿，都很容易出现数据受损，比如谁都不在意的一个小调整，就可能使”客户”的”最新订单”指向一条已经软删除的订单。

 
 

如果开发者接到的要求就是从数据库中删除数据，要是不建议用软删除，那就只能硬删除了。为了保证数据一致性，开发者除了删除直接有关的数据行，还应该级联地删除相关数据。可Udi

Dahan提醒读者注意[……]

阅读全文

by ·0评论

在企业数据库设计中，经常会遇到一个需求，就是希望把操作之前的数据保留下来，能够看到操作之前是什么数据，操作之后是什么数据。对于这种需求，我们可以使用保留历史数据或者使用版本来实现。

为了能够保留历史数据，在版本设计时有以下方案：

一、使用版本号

版本号是一种常见的版本设计方案，就是在要进行历史数据保留的表上面增加一个版本号字段，该字段可以是DateTime类型，也可以是int类型，每进行数据操作时，都是创建一个新的版本，版本是只增不减的，所以只需要拿到最大一个版本号，就能得到最新的业务数据。

版本号除了能够用于留存历史数据外，还有一个功能就是避免并发编辑操作。比如我们有一个对象A，当前的版本是1，两个用户同时打开了该对象的编辑页面，进行数据更改。先是甲用户提交更改，这个时候系统把对象的ID和版本进行查询，发现要修改的数据最新版本是1，所以成功修改，保存了对象A的新版本2。这个时候用户乙也提交了修改。系统把对象的ID和版本1进行查询，发现要修改的数据最新版本是2，不符合要求，所以拒绝用户乙的修改。用户乙只有刷新界面，拿到最新的版本2，再进行修改。

ID

单号

[……]

阅读全文

by ·0评论

在存储标题、网址等一系列不长不短的内容时，字段类型我们可能选择 varchar(255) 或者 varchar(256)，使用哪个好呢？

有些人选择 varchar(255)，可能来源于以下两个原因：

  • tinyint 类型存储的最大数字是 255，诱导我们设置 varchar 时也不要突破 255，实际上 tinyint 存储的是 0-255 一共 256 个数字。
  • Access 中文本的最大长度是 255。

实际上建议使用 varchar(256)，因为这是一个字节的内容，微软设计的数据库中使用的就是 256，而不是 255。

by ·0评论

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。