HDC調(diào)試需求開發(fā)（15萬預(yù)算）,能者速來！>>>
按照網(wǎng)上的一些例子,配置了xdebug(php版本是7.0),啟動應(yīng)該是正常的
我使用的是php自帶的web服務(wù)器運行的,啟動后phpinfo()已經(jīng)打出了xdebug相關(guān)的信息了,但是用netbeans連接始終不行
有的說是netbeans作為服務(wù)端啟動一個端口(默認為9000),但感覺應(yīng)該是服務(wù)端(也就是php端啟動一個xdebug的端口,類似java的調(diào)試模式)
我的php.ini配置如下:
zend_extension="E:/php-7.0.13-Win32-VC14-x64/ext/xdebug-2.5.0rc1-7.0-vc14-x86_64.dll" xdebug.profiler_enable=on xdebug.remote_enable=On xdebug.remote_handler=dbgp xdebug.remote_host=localhost xdebug.remote_port=9000
phpinfo()顯示的xdebug信息如下:
xdebug
xdebug support enabled
Version
IDE Key
2.5.0rc1 | netbeans-xdebug
Supported protocols Revision
DBGp - Common DeBuGger Protocol
$Revision: 1.145 $
Directive Local Value Master Value | xdebug.auto_trace | Off | Off |
|---|
| xdebug.cli_color | 0 | 0 | | xdebug.collect_assignments | Off | Off | | xdebug.collect_includes | On | On | | xdebug.collect_params | 0 | 0 | | xdebug.collect_return | Off | Off | | xdebug.collect_vars | Off | Off | | xdebug.coverage_enable | On | On | | xdebug.default_enable | On | On | | xdebug.dump.COOKIE | no value | no value | | xdebug.dump.ENV | no value | no value | | xdebug.dump.FILES | no value | no value | | xdebug.dump.GET | no value | no value | | xdebug.dump.POST | no value | no value | | xdebug.dump.REQUEST | no value | no value | | xdebug.dump.SERVER | no value | no value | | xdebug.dump.SESSION | no value | no value | | xdebug.dump_globals | On | On | | xdebug.dump_once | On | On | | xdebug.dump_undefined | Off | Off | | xdebug.extended_info | On | On | | xdebug.file_link_format | no value | no value | | xdebug.force_display_errors | Off | Off | | xdebug.force_error_reporting | 0 | 0 | | xdebug.halt_level | 0 | 0 | | xdebug.idekey | no value | no value | | xdebug.max_nesting_level | 256 | 256 | | xdebug.max_stack_frames | -1 | -1 | | xdebug.overload_var_dump | 2 | 2 | | xdebug.profiler_aggregate | Off | Off | | xdebug.profiler_append | Off | Off | | xdebug.profiler_enable | Off | Off | | xdebug.profiler_enable_trigger | Off | Off | | xdebug.profiler_enable_trigger_value | no value | no value | | xdebug.profiler_output_dir | C:\Windows\Temp | C:\Windows\Temp | | xdebug.profiler_output_name | cachegrind.out.%p | cachegrind.out.%p | | xdebug.remote_addr_header | no value | no value | | xdebug.remote_autostart | Off | Off | | xdebug.remote_connect_back | Off | Off | | xdebug.remote_cookie_expire_time | 3600 | 3600 | | xdebug.remote_enable | On | On | | xdebug.remote_handler | dbgp | dbgp | | xdebug.remote_host | localhost | localhost | | xdebug.remote_log | no value | no value | | xdebug.remote_mode | req | req | | xdebug.remote_port | 9000 | 9000 | | xdebug.scream | Off | Off | | xdebug.show_error_trace | Off | Off | | xdebug.show_exception_trace | Off | Off | | xdebug.show_local_vars | Off | Off | | xdebug.show_mem_delta | Off | Off | | xdebug.trace_enable_trigger | Off | Off | | xdebug.trace_enable_trigger_value | no value | no value | | xdebug.trace_format | 0 | 0 | | xdebug.trace_options | 0 | 0 | | xdebug.trace_output_dir | C:\Windows\Temp | C:\Windows\Temp | | xdebug.trace_output_name | trace.%c | trace.%c | | xdebug.var_display_max_children | 128 | 128
xdebug.var_display_max_data | xdebug.var_display_max_depth
512 | 3
512 | 3 |
HDC調(diào)試需求開發(fā)（15萬預(yù)算）,能者速來！>>>
netbeans（7.0.1）剛啟動的時候,右鍵菜單還好好地,過一會就不能用了,變成下面那樣的一個小框,重裝了兩次,沒有用。有沒有那個大神遇到過,怎么解決的啊。。
HDC調(diào)試需求開發(fā)（15萬預(yù)算）,能者速來！>>>
PHP寫的一個驗證碼模塊,在Win環(huán)境下使用PhpStudy運行完全正常(apache+php5.4模式), 遷移到CentOS中的lnmp環(huán)境下后(php-fpm + php5.4),驗證碼顯示不出來
事情不簡單,詭異的事現(xiàn)在開始。
之前以為是文件誤帶BOM了,然后用linux查找BOM,搜索了整個網(wǎng)站目錄,無果 （ grep - r - I - l $ '^???' . / ） 。把驗證碼的PHP文件重新下到Win桌面上用16進制模式確認,也確實沒有。
最后沒辦法只能逐字節(jié)比較。以下是Win環(huán)境生成的驗證碼(第一行),和Linux生成的(第二行),發(fā)現(xiàn)前三個字節(jié)明顯就是BOM。
00000000h: 89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52 ; 塒NG........IHDR
00000000h: EF BB BF 89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 ; 锘繅PNG........I
有沒有什么好的辦法解決這種LinuxPHP環(huán)境下產(chǎn)生的神奇BOM？
產(chǎn)生兩個驗證碼的代碼文件完全一致,僅運行的環(huán)境有區(qū)別,網(wǎng)站所有文件都已經(jīng)排查了并不包含BOM。
HDC調(diào)試需求開發(fā)（15萬預(yù)算）,能者速來！>>>
確認按鈕觸發(fā)action事件,想要跳轉(zhuǎn)到二級窗體（例：frame2）,求代碼
private void jButtonOKActionPerformed(java.awt.event.ActionEvent evt) {
} 需要新建一個類嗎？
HDC調(diào)試需求開發(fā)（15萬預(yù)算）,能者速來！>>> 打開“NetBeans”, 當然要有“NetBeans”并打開它,
點開“服務(wù)”選項卡,看到“Maven”資源庫,
并右擊“添加資源庫”,注冊如下信息就完成了。 id:nexus-osc name:Nexus osc url:http://maven.oschina.net/content/groups/public/
接著在項目中就可以使用“開源中國 Maven 庫”
想要嘗試NetBeans可以直接官網(wǎng)下載： https://netbeans.org
順便問下“開源中國Ｍaven庫”檢索出來的會有多個重復(fù)項 HDC調(diào)試需求開發(fā)（15萬預(yù)算）,能者速來！>>>
SelectNextOccurrence 也不知道該翻譯成“ 選擇下一個什么 ”,默認的快捷鍵好像是ALT+J
netbeans中有嗎？ HDC調(diào)試需求開發(fā)（15萬預(yù)算）,能者速來！>>>
最近在搞 xdebug + netbeans 的調(diào)式, 現(xiàn)在遇到了問題就是,調(diào)試thinkphp里的方法的時候無法調(diào)試 會報錯
HDC調(diào)試需求開發(fā)（15萬預(yù)算）,能者速來！>>>
pwwMap包含三種map。
1、內(nèi)存map,采用獨特的索引技術(shù),性能和內(nèi)存比stl庫的map高百倍以上。
2、哈希map,完美哈希算法,無碰撞幾率。性能比目前的google哈希算法快100倍。
3、硬盤map,就是nosql數(shù)據(jù)庫。目前查詢速度最快的nosql數(shù)據(jù)庫。單表容量高達百億。
有大神誰用的這個嗎 HDC調(diào)試需求開發(fā)（15萬預(yù)算）,能者速來！>>>
mysql5.7的基本情況就不多介紹了,相比大家也知道,在低性能要求,低并發(fā),低請求,低數(shù)據(jù)量的情況下,速度還是可以的。
如果數(shù)據(jù)量過大,百萬級,如果加上索引,加上字段限制速度也還是可以的,但是我最近的項目因為涉及到點贊之類的操作,那這個數(shù)據(jù)庫的操作就相當?shù)母吡?每天光是pv就能到十幾萬,即便沒人只有3-5票,那這在高峰期肯定是宕機的,已驗證。
所有我最近又研究了一下mysql8版本,發(fā)現(xiàn)該版本操作類型被官方定義為nosql+mysql的范圍,然后我把同樣的數(shù)據(jù)庫,分別在5.7跟8做了比較,個人認為如下：
（前提：都已加索引）
1：sql
$d=Db::table("production")
->field("sum(c.fz+c.pf+c.gf+c.yf) as zf,sum(c.fz) as fz,sum(c.pf) as pf,sum(c.gf) as gf,sum(c.yf) as yf,a.jz,a.pwlll,a.dz,a.lll,a.mtype,a.id,a.userid,a.type,a.title,a.member,b.name,b.phone,b.mail,b.sf,b.city,b.school,b.zy,a.teacher,a.fb,a.hj,a.tp,a.px,a.uptime,a.face")
->alias("a")
->join("user b","a.userid=b.userid","left")
->join("pf c","a.id=c.conid","left")
->where("a.status",2)
->page($page,30)
->group("a.id")
->order("zf desc,a.tp asc,a.dz desc,a.lll desc,a.id desc")
->select();
用該sql的情況是use字段十幾萬數(shù)據(jù),production9000多,pf暫時6000多,目前用下來,mysql5.7的這一句sql就有5秒多,mysql8只有0.3秒左右。
而且mysql8查詢的時間相對穩(wěn)定,但是mysql5.7的時間變化較大、
2：sql
SELECT * FROM `fav` WHERE id>=1000000 limit 100
該表數(shù)據(jù)量大約是一百三十萬條,mysql5.7測試讀取花費1.3秒,mysql8花費0.003秒,可謂差距巨大啊。
3：我個人猜測,或許nosql的這種存儲讀取方式本身避免了邏輯性的存儲,而精確式的數(shù)據(jù)為主,所有性能提升極大。
end。
https://my.oschina.net/shuaijin/blog/3159952 HDC調(diào)試需求開發(fā)（15萬預(yù)算）,能者速來！>>>
想要弄一個內(nèi)部論壇,用sql數(shù)據(jù)庫建立跟帖子有關(guān)的數(shù)據(jù)表,比如板塊表,帖子表,回復(fù)表,回復(fù)內(nèi)容是html會有圖片,也可能是純文本,并且長度不定。
我一直猶豫要不要把帖子回復(fù)內(nèi)容存到sql數(shù)據(jù)庫里,文章長度不確定,怕會影響到查詢性能,還有一個方式,就是將評論內(nèi)容存在單獨的文件里,用文件路徑關(guān)聯(lián)這個文件,這種方式我覺得管理起來有點麻煩,近些時間了解到nosql數(shù)據(jù)庫在一些特定的領(lǐng)域性能上比sql要快一些,于是我考慮的是用sql存小數(shù)據(jù),在回復(fù)實體表里,大一點數(shù)據(jù),例如文章,回復(fù),評論一類的數(shù)據(jù),想存nosql數(shù)據(jù)庫里。
據(jù)我了解常用的nosql有圖,列,文檔,鍵值對四大類型,那么哪種類型的nosql比較適合本次所描述的？我優(yōu)先考慮java平臺,如果同時能在.net上應(yīng)用那更好。 HDC調(diào)試需求開發(fā)（15萬預(yù)算）,能者速來！>>>
主服務(wù)器BGSAVE執(zhí)行完后,為什么向所有從服務(wù)器發(fā)送rdb快照文件,比如redis cluster 1主4從,當需要增加slave節(jié)點時執(zhí)行這樣的操作：1.slave5 啟動--> 2.發(fā)送sync指令-->3.master收到指令執(zhí)行bgsave命令-->4.master bgsave執(zhí)行完成后向所有slave節(jié)點發(fā)送rdb快照-->5.slaves節(jié)點接收rdb文件,接收完成后更新數(shù)據(jù)。
問題發(fā)生在4,為什么會向所有的slave節(jié)點發(fā)送rdb快照進行全量更新,一個是對master節(jié)點的服務(wù)器資源消耗、帶寬消耗,slave節(jié)點接收資源時也會占用大量的資源,有大佬方便指點下嗎？ HDC調(diào)試需求開發(fā)（15萬預(yù)算）,能者速來！>>>
受訪嘉賓：山寶銀 | 作者：h4cd
當你在電商平臺秒殺商品或者在社交網(wǎng)絡(luò)刷熱門話題的時候,可以很明顯感受到當前網(wǎng)絡(luò)數(shù)據(jù)流量的恐怖,幾十萬商品剛開搶,一秒都不到就售罄；哪個大明星出軌的消息一出現(xiàn),瞬間閱讀與轉(zhuǎn)發(fā)次數(shù)可以達到上億。作為終端用戶的我們可能會思考,服務(wù)系統(tǒng)是怎么在這樣嚴峻的流量環(huán)境中存活下來的。
其實,服務(wù)系統(tǒng)的架構(gòu)中有許多巧妙的設(shè)計來應(yīng)對這樣的問題,而在這其中,通常系統(tǒng)都會架設(shè)緩存系統(tǒng),用以緩解海量訪問請求與數(shù)據(jù)帶來的沖擊,實現(xiàn)高性能訪問需求。
同時,隨著微服務(wù)與云等技術(shù)的發(fā)展,分布式架構(gòu)的需求變得越來越普遍,再加上今天 Web 上的數(shù)據(jù)類型已經(jīng)不再單一,而且數(shù)據(jù)量也呈爆發(fā)式增長,傳統(tǒng)的結(jié)構(gòu)化存儲方案已經(jīng)跟不上腳步,對數(shù)據(jù)庫的 SQL 操作不再滿足要求,于是 NoSQL 出現(xiàn)。
將這幾種技術(shù)方案整合起來,我們可以設(shè)計出分布式 NoSQL 緩存系統(tǒng),當前這一類系統(tǒng)有一些比較強大的開源方案,比如 Memcached 和 Redis,它們對整個服務(wù)系統(tǒng)的可用性、可擴展性與性能起到至關(guān)重要的作用。
聽說最近騰訊開源了一個分布式 NoSQL 存儲系統(tǒng) DCache,它的典型應(yīng)用場景就在分布式緩存。根據(jù)官方介紹,DCache 基于 TARS 微服務(wù)治理方案,它支持 k-v、k-k-row、list、set 與 zset 多種數(shù)據(jù)結(jié)構(gòu),數(shù)據(jù)基于內(nèi)存存儲,同時支持后接 DB 實現(xiàn)數(shù)據(jù)持久化。DCache 具備快速水平擴展能力,同時配套有 Web 運維平臺實現(xiàn)高效的運維操作。
我們第一時間采訪了 DCache 研發(fā)團隊成員山寶銀,希望對項目的研發(fā)背景與相關(guān)技術(shù)細節(jié)有進一步了解。
DCache： https://www.oschina.net/p/dcache-nosql
當前開源的分布式緩存系統(tǒng)中,Memcached 與 Redis 是很普遍的選擇,騰訊此次為什么要自己造一個系統(tǒng)呢？
山寶銀介紹,雖然 Memcached 與 Redis 本身都擁有極其強大的能力,但是存在運維困難、缺乏集群化方案與無法應(yīng)對微服務(wù)趨勢帶來的挑戰(zhàn)等問題。
舉個例子,當前微服務(wù)是一大趨勢,大家都在說要做微服務(wù),它可以讓計算與存儲之間解耦,實現(xiàn)輕量級通信。微服務(wù)不需要管理生命同期,而作為系統(tǒng)組件的 Redis 則不然,“我們做服務(wù)架構(gòu)設(shè)計時希望把邏輯層和數(shù)據(jù)層分離開來,但是如果使用 Redis 做緩存,緩存與 DB 之間的數(shù)據(jù)一致性問題,以及緩存不命中如何解決等問題都需要使用者在業(yè)務(wù)邏輯中做相關(guān)處理,這增加了一定的復(fù)雜度和難度,也增加了邏輯層和數(shù)據(jù)層的耦合度?！?
另一方面,山寶銀介紹,起初面對海量數(shù)據(jù)和高性能訪問需求,騰訊內(nèi)部各個團隊其實都開發(fā)了各自的緩存系統(tǒng),然而這些系統(tǒng)之間協(xié)議不統(tǒng)一、服務(wù)模型多樣化、不具有通用性容錯、擴展能力也參差不齊,所以團隊就著手研發(fā)了 DCache 這一套通用 Cache 系統(tǒng),希望整體去解決業(yè)務(wù)、開發(fā)、運維和監(jiān)控面臨的各種挑戰(zhàn)。
所以也可以看到,目前 DCache 已經(jīng)應(yīng)用于騰訊內(nèi)部多個業(yè)務(wù)上,包括 QQ 瀏覽器、應(yīng)用寶、騰訊地圖、騰訊電腦管家、手機管家與騰訊游戲等。
SQL、分布式與 NoSQL 的取舍
SQL 是指數(shù)據(jù)庫的結(jié)構(gòu)化查詢語言,它是數(shù)據(jù)庫的操作命令集,傳統(tǒng)的關(guān)系型數(shù)據(jù)庫都使用標準的 SQL 語句操作處理數(shù)據(jù)。分布式是軟件系統(tǒng)的一種架構(gòu)模式,在分布式系統(tǒng)中,多個硬件或軟件組件分布在不同計算機上,彼此之間通過消息傳遞進行通信,對外表現(xiàn)為一個整體,提供統(tǒng)一化的服務(wù)。
有一種普遍的觀點是,數(shù)據(jù)庫 SQL 與分布式之間存在天然對立性,山寶銀的理解是：“分布式系統(tǒng)因為數(shù)據(jù)分散在不同的節(jié)點,所以像 SQL 的聯(lián)表、事務(wù)等操作需要全局的鎖保護,這樣處理起來比較復(fù)雜,并且影響性能?！?
SQL 還有與 NoSQL 的取舍問題,NoSQL 是指一類數(shù)據(jù)庫,主要用于高性能處理超海量數(shù)據(jù),它的一大特點是數(shù)據(jù)結(jié)構(gòu)簡單,以 key-value 為主,數(shù)據(jù)之間非關(guān)聯(lián),容易做水平擴展。
從字面上看,NoSQL 似乎是與 SQL 對立的,做 NoSQL 似乎就意味著放棄 SQL,然而實際上 NoSQL 本意是 Not Only SQL,它不僅僅是 SQL,那么也就可以包含 SQL 的能力。
“NoSQL 也不是一定就得放棄 SQL,其實在代理層可以增加 SQL 的解析、計算邏輯來實現(xiàn) SQL 操作,但這樣會影響性能,所以還是看應(yīng)用場景和業(yè)務(wù)需求。”
山寶銀為我們簡單分析了 DCache “分布式 NoSQL”的意義。在 SQL 處理方面,分布式似乎存在劣勢,然而分布式意味著可以聯(lián)結(jié)更多的廉價計算機,充分運用算力,以低成本的方式應(yīng)對高強度的并發(fā)訪問請求,此外分布式架構(gòu)還有不少優(yōu)勢,比如避免系統(tǒng)單點問題導(dǎo)致的整體故障,實現(xiàn)高可用。
而另一方面,山寶銀也說到：“DCache 因為主要的目標就是高性能,SQL 操作并不是主要想解決的問題,所以 DCache 沒有實現(xiàn) SQL 的功能。”
DCache 分布式策略與能力
DCache 對外提供服務(wù)的粒度是 group,一個 group 負責一部分的數(shù)據(jù)分片,至于每個 group 服務(wù)哪些數(shù)據(jù),是根據(jù)數(shù)據(jù)的 key 做 hash 映射后所處的范圍來確定的。
DCache 會把數(shù)據(jù)的 key 通過 hash 算法映射到 0～4294967295 (unsigned int) 范圍內(nèi),然后把 0～4294967295 范圍均勻劃分到不同的 group 上。例如有兩個 group,key 做 hash 后的值在 0～2147483647 范圍就分發(fā)到 group1,在 2147483648～4294967295 范圍就分發(fā)到 group2。
在一個 group 內(nèi),采用主備架構(gòu),只有主節(jié)點接收讀寫請求,所以數(shù)據(jù)一致性是可以保證的,而當主機不可用時,會觸發(fā)主備自動切換,保證服務(wù)持續(xù)可用。
DCache 架構(gòu)
我們疑惑 DCache 似乎強依賴于 etcd 與 TARS 等中間件,那它本身的 核心特性與能力 體現(xiàn)在哪里？
山寶銀解釋,DCache 并不強依賴 etcd,“etcd 只涉及了路由服務(wù) RouterServer 的選主,如果 RouterServer 部署單點也是可用的,而且 RouterServer 的宕機不會影響到數(shù)據(jù)的讀寫訪問,因為所有的 Proxy 與 Cache 服務(wù)都有本地的路由緩存”,關(guān)于 TARS 的采用,他說：“因為 TARS 是一個非常優(yōu)秀的服務(wù)開發(fā)框架,它屏蔽了底層的網(wǎng)絡(luò)通信細節(jié),且自帶了名字服務(wù)等很多服務(wù)化需要的功能,對于 DCache 來說,使用已有的 TARS 框架可以更好地做到服務(wù)化,我們沒有必要去重復(fù)的造輪子?！?
至于 DCache 本身的能力,山寶銀介紹：“DCache 自身的存儲引擎具有很高的性能,而且支持后接 DB,對使用者來說,不需要再關(guān)心 DB 和緩存之間的數(shù)據(jù)一致性,以及緩存不命中帶來的一系列問題?！?
具體來說,DCache 持久化與 Redis 不一樣,后者只是把內(nèi)存中的數(shù)據(jù)在本地磁盤做一個備份,保證 Redis 重啟之后做數(shù)據(jù)恢復(fù)。
“Redis 持久化主要是為了數(shù)據(jù)備份。DCache 后端有了 DB 以后,業(yè)務(wù)的邏輯與后臺的數(shù)據(jù)可以完全隔開,DCache 自身會處理緩存與 DB 之間的數(shù)據(jù)一致性問題。
DCache 會不斷地將 Cache 中的數(shù)據(jù)落地后端 DB,如果 Cache 中存儲空間不夠,會將已經(jīng)落地 DB 的冷數(shù)據(jù)淘汰掉。在數(shù)據(jù)查詢的過程中,如果查詢 Cache 不命中,會從 DB 讀取并重新存到 Cache,以此來保證 Cache 中數(shù)據(jù)的熱點性和命中率,同時 DB 與 Cache 的穿透問題也得到解決。
另外,數(shù)據(jù)持久化到后端 DB 的能力對于一些需要做離線數(shù)據(jù)分析的業(yè)務(wù)場景也比較方便?？傊阃耆挥藐P(guān)心數(shù)據(jù)的東西,只需要把數(shù)據(jù)寫到 Cache,后端的落地由 DCache 處理。”
DCache 特性
此外,DCache 的分布式集群化、異地鏡像部署、容災(zāi)容錯能力在實際線上應(yīng)用中都會提供非常高的價值。
用武之地
作為一個分布式存儲系統(tǒng),DCache 的應(yīng)用場景沒有限制在緩存上,山寶銀介紹,對于有高性能 NoSQL 存儲需求的場景,都可以使用 DCache,而且因為 DCache 具備容量淘汰與過期自動清理數(shù)據(jù)的功能,對于需要存儲熱點數(shù)據(jù)（如熱門文章）與臨時數(shù)據(jù)（如有時效性的聊天記錄）的場景也可以提供很好的支持。
山寶銀也提供了 DCache 的性能數(shù)據(jù)：
目前騰訊內(nèi)部包括 QQ 瀏覽器、應(yīng)用寶、騰訊地圖、騰訊電腦管家、手機管家與騰訊游戲在內(nèi)的近百個業(yè)務(wù)都接入了 DCache,這些業(yè)務(wù)的體量之大可以想象,山寶銀補充：“除了提供的這一組簡單的數(shù)據(jù),DCache 在高效可靠地支撐著近百個業(yè)務(wù)的運轉(zhuǎn),日均調(diào)用量過萬億次,這也從側(cè)面說明了 DCache 在生產(chǎn)環(huán)境的性能與穩(wěn)定性。”
而除了系統(tǒng)本身高性能、高擴展、高可用與數(shù)據(jù)安全的設(shè)計外,Web 可視化的高效運維平臺也成了 DCache 不可或缺的重要能力?；趦?nèi)存的 NoSQL 存儲系統(tǒng)在運維上會產(chǎn)生巨大的額外開銷,它需要對相關(guān)技術(shù)進行深入理解,并且在緊要關(guān)頭果斷做出正確決策。
DCache 基于 TARS 開發(fā),所以運維平臺將 DCache 與 TARS 的服務(wù)管理統(tǒng)一做在了一個模塊上,山寶銀介紹該運維平臺將大大提高效率,同時降低了運維門檻,關(guān)于服務(wù)的部署、上線、遷移、擴容、監(jiān)控與配置這些操作都可以輕松實現(xiàn)。
嘉賓介紹
山寶銀,騰訊后臺高級工程師,專注于分布式 NoSQL 存儲領(lǐng)域的技術(shù)研發(fā)工作,參與騰訊多個自研存儲系統(tǒng)的開發(fā),在分布式系統(tǒng)、高可用與高性能服務(wù)等領(lǐng)域有較豐富的經(jīng)驗。 HDC調(diào)試需求開發(fā)（15萬預(yù)算）,能者速來！>>>
Restful API可以將所有的模型都看做資源。
直接操作這些資源（CRUD）,很容易就可以控制；
但,資源之間如果是一個網(wǎng)狀的關(guān)系,而不是樹,這樣的權(quán)限設(shè)計,怎么做呢？
示例場景描述：
問題描述 我模擬一種異常情況。
假設(shè),我沒有 修改章節(jié)的 權(quán)限,但,訪問下面的地址,是否可以做到？
url：PUT/知識點/知識點ID/章節(jié)/章節(jié)ID
json data：與章節(jié)Model完全匹配的數(shù)據(jù)
| 
.png)
大數(shù)據(jù)引擎.png)
大數(shù)據(jù)應(yīng)用.png)
大數(shù)據(jù)底層技術(shù).png)
ForeSpider軟件
.png)
采集服務(wù).png)
軟件學(xué)習(xí).png)
智能分析.png)
特征提取.png)
智能計算.png)
數(shù)據(jù)可視化.png)
數(shù)據(jù)分析應(yīng)用.png)
系統(tǒng)集成服務(wù).png)
代碼工具.png)
金融方案.png)
制造業(yè)&物流.png)
企業(yè)數(shù)字化.png)
醫(yī)療方案.png)
政務(wù)方案.png)
實時監(jiān)測.png)
智能分析.png)
數(shù)據(jù)智能挖掘.png)
全網(wǎng)自動采集.png)
場景智慧采集.png)
主題識別采集
注冊即送：30天知析標訊會員權(quán)益
022-2345 2937
185 2247 0110
business@forenose.com
客服微信
訂閱號
服務(wù)號
022-2345 2937
185 2247 0110（同微信）
business@forenose.com
2779623375
前嗅大數(shù)據(jù)